Apparently It’s OK For iOS Apps To Ask For Your Apple ID And Password | Hacker News Reader

Apparently It’s OK For iOS Apps To Ask For Your Apple ID And Password

marco.org

262 pointsshawndumas105 comments

Hey everybody, Pierre from @sunrise. This is the blog post we've just published to give more context:

"Users sometimes ask us why we require the user’s Apple ID and password in Sunrise, instead of using the local Calendar API. That’s a great question to ask, and we understand why users don’t want to share their credentials without context. We’ve thought a lot about that.

The two reasons why we are doing this are: - one, to provide a better user-experience - two, to offer a Sunrise experience everywhere, on all platforms (including web and Android)

Providing a better user-experience

Being able to access the data from our servers, instead of just client-side, has enabled us to write a better calendar app. We are working hard to make synchronization faster and more reliable, and it enables us to send push notifications or alerts to users without them having to open the app.

And this is just the beginning, a lot of new features that we are working on at Sunrise for the future will rely on our server-side infrastructure.

Sunrise everywhere

The two biggest feature requests we get from users are: “when is Sunrise going to launch on desktop” and “what about Android?”.

We understand our users, they want a unified Sunrise experience everywhere, and so we can’t use a local API for that.

How does it work? Is this secure?

When you type in your iCloud credentials, they are sent to our server only once in a secured way over SSL. We use them to generate a secure token from Apple. This secure token is the only thing we store on our servers, we never store your actual iCloud credentials.

What’s next?

In the future, we are thinking about ways to take advantage of the local Calendar API for users who don’t want to share their credentials, we understand their point of view.

We are also hoping that Apple will leverage OAuth to authenticate their calendar API, which will make things easier for everyone. We already support OAuth with Facebook, Google, Twitter, LinkedIn, Foursquare and Producteev. We support OAuth where we can.

We are a team of 7 people building a calendar with love & passion, and unfortunately we can’t always move as fast as we want, but as always, we want to address users’ issues with transparency and openness. We’re listening on @sunrise or support@sunrise.am"

Submitting credentials "only once to our server" is a classical fishing attack. There is no way for the user to verify what happen with them.

Seriously, there's no way for the user to verify what happens with them even if they don't send them to the server and generate the token in the app. They could still just encrypt them and hide them in the requests they send to their servers to retrieve calendar data. It's fundamentally a matter of trust, made worse by the fact that apple obviously doesn't offer oauth or a similar mechanism.

The one rather glaring fly in your ointment is that if your system was as secure as you make it out to be you wouldn't have been asking users to change their iCloud passwords after your database was compromised a few months ago.

http://www.theverge.com/2013/11/3/5061136/sunrise-calendar-a...

Ouch.

I guess they have done that for triggering a reset of the validity of the "apple token" that was compromised.

In fairness, changing your password also deactivates any login tockens associated with the old password.

If you delete the app, this won't remove the account from sunrise's system then?

There is no way for app developers to know which users have deleted the app from their device.

Not exactly true. If you send a push notification to a device using a token of an app that isn't installed anymore, the feedback service will let you know that the app isn't installed on the device anymore[0].

[0] https://developer.apple.com/library/ios/documentation/Networ...

What about users who didn't allow location services to begin with?

Why not generate token on client and only submit that?

Can you explain how it is possible to generate secure tokens? I can't find anything related to it from the iCloud documentations.

I'm guessing, that they simulate an iCloud login and then store the cookie on their servers and then use that cookie to login in the future?

But thinking about it, it's a CalDAV server which normally uses email + password to authenticate..

Why don't you run your own caldav server instead of relying upon icloud?

People want access to their apple calendar, on all their devices.

They should have rejected your app until they had an Oauth solution in place. That's the right answer to avoid training Apple users to be fishing targets.

Sunrise doesn't have a (known) security problem. Sunrise happened to reveal a glaring problem with Apple's security policies.

It's actually phishing. I bring it up because I see more than one commenter on this page that has it wrong.

it might be autocorrect changing phishing to fishing

Anyone who is relying on autocorrect while posting comments on technical issues kinda deserves what they get.

fwiw. I typed phishing on my iPad and it worked fine.

Actually, as a poster mentioned above, Sunrise was compromised 3 months ago, and recommended all iCloud users change their passwords.

http://www.theverge.com/2013/11/3/5061136/sunrise-calendar-a...

How would OAuth help? The problem is training users that it's okay to enter their username and password into any schmuck's app... which is exactly what they'd be doing with OAuth. OAuth and its ilk are neat ways for honest app developers to avoid touching user credentials, and therefore (presumably) would have been a better solution for Sunrise, but they offer no protection against phishing in a native app.

Of course, OS X Authorization Services prompts for keychain access with a standard dialog that just pinky-swears it comes with the OS's blessing, so maybe Apple's approval of this practice shouldn't come as such a surprise.

Unfortunately, you are asking your users to engage in an inherently unsafe behaviour. Even if your implementation is rock solid, users shouldn't get used to supplying AppleID credentials to random applications.

We understand our users, they want a unified Sunrise experience everywhere, and so we can’t use a local API for that.

Of course you can, but you need to do extra work to store and synchronise calenders.

How many users would understand the calendar integration hiccups because their iPhone didn't have data coverage or was off or ...?

Not to play doomsday profet but: Apple does not want you to be able to use some other application to access data that apple is already having an application for. So expect to be shut down when apple finally realizes what your app is for.

Unless I'm misunderstanding your point, you seem to be ignoring the numerous third-party calendar iOS apps that access and manipulate your calendar. I'm using one called Fantastical, but there are many others.

Fantastical uses EventKit. As do many of the other calendar apps.

In your giant ad you missed the point so much it hurts.

You are asking sensitive user names and passwords you have no right to have. Just because you don’t do anything bad with them (that you say - and not yet) means nothing. You shouldn't be asking for them. Phishing attacks do exactly the same thing you do. You are not special, your users shouldn't trust you with their appleid and password anymore than any other spam email they get.

Why does the application that accesses your calendar not have the right to the credentials for those calendars. Does my email application all of a sudden no longer have the right to my email credentials.

The issue here is not that Sunrise asks for your iCloud credentials, which it needs to be able to access your iCloud data, which you as a user of their service have given them the right to. The problem is that those same credentials are tied to your iTunes account and your credit card.

Think cloud based. OAuth, if implemented by Apple, would have APPLE asking the users for their username / password combination. APPLE then tells Sunrise that the username / password is valid. There is no reason why Sunrise should ask for the username / password.

OAuth and even older, Paypal, use this methodology. It is a shared deficiency between Sunrise and Apple that they don't have a better way of performing user authentication.

-----------------

Your email application is a null / void example. Email applications run on your own computer. What is going on here is that Sunrise is collecting usernames / passwords on their own server, and promising that they won't do anything wrong with them. Whether or not we should trust them is beside the point, their approach to security is terrible.

I don't think anyone would disagree that OAuth is a far, far better solution. But there's not really anything Sunrise can do to make Apple implement OAuth.

"We are a team of 7 people building a calendar with love & passion"

Love and passion?

Love and passion.

I wonder if the reason why they are asking for AppleID and password is because that's the only way they found to overcome the iCloud integration problem described back in April/2013

From http://sunrise-product.tumblr.com/post/47802736454/why-doesn...

Why doesn’t Sunrise support iCloud/Exchange yet?

Every other calendar app seems to do it, what’s taking Sunrise so long?

To explain let’s breakdown a calendar app into two parts, the presentation layer and the storage layer. In the stock iOS Calendar app, Calendar is the presentation layer and EventKit is the storage layer, both developed by Apple. Other calendar apps in the App Store also follow this two layer design but only redevelop the presentation layer while continuing to use Apple’s EventKit storage layer. In other words, these apps quite literally take your data and dress it up in a different color. What we do at Sunrise is redevelop both the presentation layer and the storage layer.

You guys are crazy, why bother reinventing EventKit?

The storage layer is responsible for keeping your data in a structured format. If we were to use Apple’s EventKit storage layer, we would have no control over what can be stored and how to store it.

Okay, so what’s wrong with not having control over the storage layer?

The storage layer needs to be revolutionized. Why can’t my calendar store anything besides text? What if I wanted to attach a picture to an event? Better yet, why not a video? What about other rich media that I would want to be included?

Herein lies the problem, the current storage layer isn’t capable of storing anything other than basic data. Not only that, it only stores certain kinds of basic data: titles, descriptions, dates, etc. We want to break these barriers and let you store anything!

Revolutionary features are coming to your calendar. We’re working as fast as we can.

The only stated way they're going to 'revolutionise' calendar storage is by adding rich media? You can hack on EventKit for that - just used the notes or URL properties on EKCalendarItem.

Sorry, they're not getting my credentials.

Yeah, I'm not sure what exactly that is trying to justify but off the top of my head I can think of about 1/2 dozen different ways to tie rich media to the calendar entry. iCloud and EventKit have their issues but this just seems way wonky to me.

And even without hacking EventKit you could just base64 the media and add it as description.

I would guess that if they had another way to access your iCloud calendar from their servers they would. Apple unfortunately has everything linked to a single account without any sort of Oauth. This is more an issue with iCloud than it is with iTunes or the App Store.

It's pretty crazy that you need to use the same credentials to "buy" a $0 app as you have to remotely lock and wipe your iphone and mac.

You don't need to at all. I use two separate Apple IDs on my iOS devices.

Apple ID accounts are individually configurable for most, if not all iCloud/App Store services.

If no one uses a feature the feature might as well not exist.

Who doesn't use this feature? Single people, that's who.

People with families have known about this feature for years. The sales staff at the Apple Stores specifically bring it up.

Yeah, I suppose single people have no interest in security, so poorly devised workarounds are ok.

People may have 1+ device per person and not share them.

As plenty of people do use that feature, I'm not sure of your point.

I’m glad that you are able to understand that abstraction, but if I'm being honest, how Apple handles accounts gets way over my head — and anyone around me is baffled by it too.

To quote JWZ: "You have invoked the "Oh, but there's a preference to turn off that stupid behavior" defense. I am showering you with negativity."

(Yes, it's not a preference pedantically, it's an option to create multiple accounts. Still the default and most used is using one account).

I'm an engineer an I didn't know you could use two accounts for different tasks on the same device. Just never thought about it, because why would I? Not a reasonable workaround, I agree.

> Just never thought about it, because why would I?

Anyone with family members using their iTunes account would and has for many years. That's why it's there.

Everyone I know with family members tries to share a single login across all devices to share purchases.

It's there so that you can create a junk account for apps which want access to your credentials? Doubtful. Remember the context of the topic.

This thread started with:

"It's pretty crazy that you need to use the same credentials to "buy" a $0 app as you have to remotely lock and wipe your iphone and mac."

I'm having no trouble remembering the context. Why are you?

if you set up an iOS device, it specifically asks you if you want have a single Apple ID or 2 ids ( one for iTunes/App Store and another one for iCloud/FaceTime/iMessage).

It's not even default behavior to use the same account. You are required to make an explicit decision during setup whether or not you want to use the same Apple ID for iCloud and the App Store.

I thought I had to have a new device to make a new ID?

How do you do it actually?

In iOS 7, you do it under Settings/iTunes & App Store; tap "Apple ID: [whatever]" and choose "Sign out", and once signed out you'll be presented with options both to sign in under an existing Apple ID, and to create a new one. (I didn't actually do so, so there could possibly be a hoop or two to jump through which I didn't see, but I tend to doubt that.)

I cannot even find any guidance from Apple on recommended patterns for which Apple IDs should be shared, which should be individual, and so on. This isn't even a configuration option, it's a hack that happens to work. (And there's no guarantee that Apple won't change their model tomorrow, since they've never given any guidance on what those multiple AppleIDs are supposed to mean.)

http://support.apple.com/kb/HT4895

You can even use multiple accounts on a single iOS device to purchase stuff. So you can "share" apps with someone by logging in as yourself and then downlading the app.

If I've been using 1 Apple ID on my devices for the past ~4 years, how do I create two separate accounts without losing data or access to media?

Serious Question.

http://support.apple.com/kb/HT4895

That doesn't really seem to transfer existing app purchases between accounts (so updates continue to work etc). It also doesn't mention moving documents&settings&calendars from one icloud to another?

iClouds PIM stuff uses DAV for syncing. In theory they could issue separate credentials to handle PIM syncing, and keep it all transparent to the user: have an API that devs can use to request a token, or something, from Apple to access DAV, when a request is authenticated through an OS native dialog (only going through apples servers and your device) -- keeping actual iCloud credentials away from the app itself.

Admittedly, Android does it much better by providing oAuth, an easy way to get the users sign in, and of course APIs for almost all the popular features. And also, for installing $0 apps you don't need any credit card details at all. Even the buttons are different "Install" v/s "Buy".

>> Admittedly, Android does it much better by providing oAuth, an easy way to get the users sign in, and of course APIs for almost all the popular features.

First of all this has nothing to do with iOS/Android. This is an app trying to access a web service. Apple needs to provide oath or similar for accessing their iCloud services.

>> And also, for installing $0 apps you don't need any credit card details at all. Even the buttons are different "Install" v/s "Buy".

This is untrue. I couldn't download any free apps until I had setup a merchant account with credit card.

You've always been able to use Google Play for free apps without a credit card...

I got an Android device about 6 months ago and couldn't download any apps until I'd setup a credit card.

Not true. What probably happened was that your Google Play account was tied to your mobile (i.e. Verizon) account, so charges made in Google Play was pushed to Verizon, who then pushed those charges to you. T-Mobile used to do that, and I needed no credit card, until about two years ago, when one was needed because T-Mobile or Google no longer wanted to do business that way.

That's funny, I just bought a new one and can install things fine without a credit card.

Because it has always been that way. Funny would be Google asking you to setup a 'merchant' account for installing free apps.

Not sure about other countries but here, in India, we can download free apps on Android without having to setup an account with credit card.

>> First of all this has nothing to do with iOS/Android...

I know it's not. I was just hinting the plus sides of a competitive product, something the new users should know, and something Apple should learn from. It's less about the app, and more about what the app is allowed to do, yet.

>> This is untrue.

No, it's not. You mean Google asked you to setup a "Merchant" account for being a "customer" of $0 apps? ... Think again. :)

You can set up an iTunes account without a credit card quite easily too: http://support.apple.com/kb/ht2534

I would guess that most iOS users think that the confirmation message for in-app purchases (prompting you for your iCloud credentials) is from the app from which they initiated the purchase, rather than from a system service.

This probably conditions them to trust all iOS apps with their password if prompted to enter it.

Which is precisely why the thing this article is pointing out is extremely terrible - Apple should have made it a rule a long time ago that no 3rd party app can ask for Apple ID credentials.

But they dug themselves in a ditch by unifying extremely sensitive things (App Store access) & very sensitive things (email, calendar) under a single account.

A few ways to get out of that ditch:

- not allowing any iOS/Mac app store 3rd party app to ask for iCloud credentials. This will suck but at least protects the average Joe.

- forcing users to have a different password for the app store/anything that can take money from a credit card.

- using something like OAuth.

- use two step verification for app store purchases (of course, the mobile app store being on a phone makes it harder)

use two step verification for app store purchases

That's actually a great idea, and it wouldn't be hard at all, as long as they were to use TFA for all iCloud access. The second factor (e.g. a 6-digit number) could be displayed in the dialogue box asking for your password.

If it's a genuine dialogue box, no problem. If it's _not_ a genuine dialogue box, then the captured username/password is of no use, as you don't have the second factor. Replay and MITM attacks could be avoided by using a session identifier; the app wouldn't be able to get at it due to the sandbox.

Apple could just, you know, implement oauth.

OAuth only makes sense if they provide an API for iCloud calendar, which isn't the case as far as I know.

It's a bog-standard CalDAV server, which isn't an API, of course, but at the same time, it sorta is.

I'd argue that CalDAV is an API - it's specified and offers operations on data. It's not JSON-Rest but an API it is.

CalDAV most certainly is an API. It's standardized [1] and everything.

[1] http://tools.ietf.org/search/rfc4791

I can't take anyone serious when they try to justify a potential security flaw with "to provide a better user-experience".

And as for "to offer a Sunrise experience everywhere, on all platforms", but at what cost?

They can't win, can they? I'm sure if they did exactly what he suggests a long, long time ago we'd be hearing how evil they are for not allowing calendar apps to work properly on the store.

Nobody is calling anybody evil. Developers may complain that there is no server-side API for an iOS user's calendar but it's still crazy that Apple allows and promotes an app that normalises an extremely dangerous practice.

On a related note, when did it become OK for an App to ask for your credit card number to do in-app purchase? I thought that wasn't allowed.

IAP is required for virtual goods used within the app. It's fine to ask for a credit card number to purchase physical goods and services. That's why Apple hasn't shut down Uber and Square.

I am guessing you can trust the app with ur credit Card because of AppStore's rigorous entry tests?

What point are you even trying to make? You trust the app for the same reasons you trust a web site you put your credit card number into, or the card reader that the cashier uses at the local business down the street.

There are plenty of examples of apps that take credit cards for non-physical goods: http://stackoverflow.com/questions/19458610/how-do-i-take-a-...

It's actually Apple's fault, they should offer an API for this kind of thing!

It's not Apple's fault.

If I ask for your gmail user / pass is that fine because there's no API ?

If Google listed your fishing attack in a recommended app list, then yes, it would be Google's fault.

Except there is an API for Gmail.

Or ban it.

Well, they do offer an API (CalDAV); they just don't offer an oAuth solution on it.

Okay, I have a question. AppleID and pw non-withstanding, I have experienced the following. I played Where's my water2 recently and came to the end where you have to pay to get additional levels. No biggie, I did this with the first game as well. But, when I clicked the in app purchase and entered my password I was prompted with a pop saying I needed to answer my 3 security questions next. Of course I hit cancel and not okay right there.

I have never seen that an app requests the security questions when making an in app purchase. Granted it's been a while since I last made one. Can anyone tell me if this is supposed to be normal now?

I tried to talk to Disney's support but of course no answer there...

It seems Apple is keen to push the 3 security question setup after a while on app store interactions, it's probably just unfortunate that it appeared during an in-app purchase interaction.

I know this is older but just in case some one experienced the same thing, the above mentioned is true.

I experienced this on iTunes on my PC quite a while ago. And since then I have not made any purchases from the iOS device itself. I buy through the PC and then sync to my devices because of slow internet.

So now, basically when I tried to make an IAP, I got the same popup. I first thought it was the app that wanted to know my details but it really is Apple. I got this out of the way by purchasing a small, 99ct app directly from my Device. So I went into the AppStore, bought the app and the same popup came up. Since this was now in the official Apple Appstore app, I answered two of my questions, downloaded the app and now, this popup is gone and I can make IAP all I like.

I had the same request from inside one of Apple's apps. I think Apple just want you to update your security questions. I logged into the AppleID site, appleid.apple.com, and updated the questions there. Relaunched the app and no more questions.

I think you get 3 or 4 tries before they lock your account, I had gotten 1 question wrong 2x an didn't want the account locked because of a typo.

That sounds right. Although since I haven't entered my security question directly in that app, I was not asked to update them from any other App.

It just felt weird that a non Apple app suddenly asked for these things. I do use Find my Friends semi regularly in which you also login with your appleid password but so far there was never a message saying I needed to enter my security questions... weird.

The Mailbox app does the same thing, to give you access to iCloud email.

http://imgur.com/xK4Hmy2

I don't have a huge beef with this, though. I am assuming that Apple has vetted the company and the app already through their normal process of allowing the app in the app store. Am I being overly trusting?

Yes.

Reply on news.ycombinator.com