13 ms·

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

262 points by shawndumas 13y ago

Touche 13y ago
Apple could just, you know, implement oauth.
- barumrho 13y ago
  OAuth only makes sense if they provide an API for iCloud calendar, which isn't the case as far as I know.
  - zw 13y ago
    It's a bog-standard CalDAV server, which isn't an API, of course, but at the same time, it sorta is.
    - Xylakant 13y ago
      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.
    - aaronem 13y ago
      CalDAV most certainly is an API. It's standardized [1] and everything. [1] http://tools.ietf.org/search/rfc4791 http://tools.ietf.org/search/rfc4791
rahimnathwani 13y ago
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.
- GuiA 13y ago
  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)
  - rahimnathwani 13y ago
    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.
pat2man 13y ago
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.
- 0x0 13y ago
  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.
  - runjake 13y ago
    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.
    - jmathai 13y ago
      If no one uses a feature the feature might as well not exist.
      - yardie 13y ago
        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.
        EpicEng 13y ago
        Yeah, I suppose single people have no interest in security, so poorly devised workarounds are ok.
        ay 13y ago
        People may have 1+ device per person and not share them.
zw 13y ago
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.
- po 13y ago
  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.
FigBug 13y ago
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.
- cmelbye 13y ago
  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.
  - xerophtye 13y ago
    I am guessing you can trust the app with ur credit Card because of AppStore's rigorous entry tests?
    - cmelbye 13y ago
      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.
  - smithereens 13y ago
    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-credit-card-subscription-in-my-iphone-app http://stackoverflow.com/questions/19458610/how-do-i-take-a-...
way66 13y ago
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"
- fhars 13y ago
  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.
  - 13y ago
piyush_soni 13y ago
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".
- k-mcgrady 13y ago
  >> 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.
  - rajivm 13y ago
    You've always been able to use Google Play for free apps without a credit card...
    - k-mcgrady 13y ago
      I got an Android device about 6 months ago and couldn't download any apps until I'd setup a credit card.
      - deleted 13y ago
        [deleted]
    - omnipath 13y ago
      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.
schappim 13y ago
It's actually Apple's fault, they should offer an API for this kind of thing!
- supercoder 13y ago
  It's not Apple's fault. If I ask for your gmail user / pass is that fine because there's no API ?
  - kevinpet 13y ago
    If Google listed your fishing attack in a recommended app list, then yes, it would be Google's fault.
  - abraham 13y ago
    Except there is an API for Gmail.
- robmcm 13y ago
  Or ban it.
- rsynnott 13y ago
  Well, they do offer an API (CalDAV); they just don't offer an oAuth solution on it.
yaeger 13y ago
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...
- 0x0 13y ago
  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.
  - yaeger 13y ago
    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.
- yardie 13y ago
  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.
msantos 13y ago
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?
msantos 13y ago
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-doesnt-sunrise-support-icloud-exchange-yet 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.
- coob 13y ago
  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.
  - jaegerpicker 13y ago
    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.
smackfu 13y ago
The Mailbox app does the same thing, to give you access to iCloud email. http://imgur.com/xK4Hmy2 http://imgur.com/xK4Hmy2
deleted 13y ago
[deleted]
bhartzer 13y ago
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?
- piyush_soni 13y ago
  Yes.

262 points by shawndumas 13y ago

Touche 13y ago

Apple could just, you know, implement oauth.

barumrho 13y ago
OAuth only makes sense if they provide an API for iCloud calendar, which isn't the case as far as I know.
- zw 13y ago
  It's a bog-standard CalDAV server, which isn't an API, of course, but at the same time, it sorta is.
  - Xylakant 13y ago
    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.
  - aaronem 13y ago
    CalDAV most certainly is an API. It's standardized [1] and everything. [1] http://tools.ietf.org/search/rfc4791 http://tools.ietf.org/search/rfc4791

rahimnathwani 13y ago

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.

GuiA 13y ago
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)
- rahimnathwani 13y ago
  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.

pat2man 13y ago

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.

0x0 13y ago
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.
- runjake 13y ago
  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.
  - jmathai 13y ago
    If no one uses a feature the feature might as well not exist.
    - yardie 13y ago
      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.
      - EpicEng 13y ago
        Yeah, I suppose single people have no interest in security, so poorly devised workarounds are ok.
      - ay 13y ago
        People may have 1+ device per person and not share them.

zw 13y ago

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.

po 13y ago
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.

FigBug 13y ago

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.

cmelbye 13y ago
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.
- xerophtye 13y ago
  I am guessing you can trust the app with ur credit Card because of AppStore's rigorous entry tests?
  - cmelbye 13y ago
    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.
- smithereens 13y ago
  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-credit-card-subscription-in-my-iphone-app http://stackoverflow.com/questions/19458610/how-do-i-take-a-...

way66 13y ago

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"

fhars 13y ago
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.
- 13y ago

piyush_soni 13y ago

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".

k-mcgrady 13y ago
>> 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.
- rajivm 13y ago
  You've always been able to use Google Play for free apps without a credit card...
  - k-mcgrady 13y ago
    I got an Android device about 6 months ago and couldn't download any apps until I'd setup a credit card.
    - deleted 13y ago
      [deleted]
  - omnipath 13y ago
    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.

schappim 13y ago

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

supercoder 13y ago
It's not Apple's fault. If I ask for your gmail user / pass is that fine because there's no API ?
- kevinpet 13y ago
  If Google listed your fishing attack in a recommended app list, then yes, it would be Google's fault.
- abraham 13y ago
  Except there is an API for Gmail.
robmcm 13y ago
Or ban it.
rsynnott 13y ago
Well, they do offer an API (CalDAV); they just don't offer an oAuth solution on it.

yaeger 13y ago

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...

0x0 13y ago
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.
- yaeger 13y ago
  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.
yardie 13y ago
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.

msantos 13y ago

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?

msantos 13y ago

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-doesnt-sunrise-support-icloud-exchange-yet 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.

coob 13y ago
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.
- jaegerpicker 13y ago
  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.

smackfu 13y ago

The Mailbox app does the same thing, to give you access to iCloud email. http://imgur.com/xK4Hmy2 http://imgur.com/xK4Hmy2

deleted 13y ago

[deleted]

bhartzer 13y ago

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?

piyush_soni 13y ago
Yes.