Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

App-specific passwords confusion

I was recently prompted to generate an app-specific password for iMessage and FaceTime on OS X, and I found the whole process rather confusing.


The reason I found it confusing is that I'd previously been through a similar process with Google which seemed to encourage me to generate a separate app-specific password for each app on each device.


But with Apple's app specific passwords I ended up using the same app-specific password for all of the following:

  • Messages on OS X
  • FaceTime on OS X
  • A really annoying mystery iCloud login prompt on OS X which doesn't tell you which app it's prompting for, it just demands your iCloud password
  • Messages on iOS
  • FaceTime on iOS


But it is not obvious whether this is what I was meant to do. The Apple help page on app-specific passwords is rather unhelpful - it doesn't even mention which of Apple's own apps require app-specific passwords (such as iMessage and FaceTime), let alone clarify whether you can/should use the same password for those apps on different devices, or how you're meant to respond to random mystery iCloud login prompts that pop-up from time-to-time (generate a new app-specific password? Re-use the existing one? Not at all clear.)


The actual enrolment process works by demanding your Apple ID password, then chastising you for entering the wrong password, followed by prompting you to visit https://appleid.apple.com/ and generate an app-specific password "for iMessage and FaceTime". But the subsequent random mystery iCloud login prompts make no mention of iMessage or FaceTime, which is why it's difficult to know how to respond.


Allegedly a similar process is meant to happen on iOS - but the iOS dialog pictured in this arstechnica article never appeared for me on iOS; I just got various Apple ID password prompts which rejected my Apple ID password, but appeared to accept the app-specific password that I'd previously generated on OS X. ("Appeared to accept" of course means the dialog disappears, they don't actually say anything helpful).


A further annoyance is that when any kind of iCloud password prompt appears on iOS, the prompt is modal, which makes it impossible to paste in the app-specific password that I'd saved into my password manager app (1Password). So I had to cancel that dialog and force a re-login to iMessage and FaceTime by turning them off and on again, just so I could paste the password in. But this had the side-effect of disabling Text Message Forwarding, so I had to re-enrol that service.


As I said, I got it all working in the end by simply generating one app-specific password and using it in all 5 scenarios above - but it took a lot of trial-and-error to get there and it wasn't straightforward at all.


God knows how someone who is not IT literate can make any sense of this.

iMac (27-inch, Late 2012), OS X Yosemite (10.10.2), null

Posted on Mar 14, 2015 5:32 AM

Reply
15 replies

Mar 16, 2015 3:57 AM in response to enteq

A very useful summary enteq. Entered a new password on the iMac, thanks to your explanation. It worked. Then the iPad required the password to be be copied down then entered manually into the iOS device, as it refused to recognise any paste attempt. Password not easily found on keychain! There are 7 password related entries generated around this simple event, some of which are seemingly empty, or have any date inaccessible. Weirdly unfriendly to users.

Apr 13, 2015 3:36 PM in response to JBA

More confusion and trial-and-error - after upgrading to iOS 8.3, my phone prompted me for "Apple ID Password" with the message "iCloud Backup requires that you verify the password for the account [email]".


I have no idea whether it wants my original Apple ID password, or my new app-specific Apple ID password.


I tried my app-specific password, and it rejected it. So then I tried my original Apple ID password, and it appeared to accept it. This is despite the fact that it's a single-factor login with no 2-step verification which implies it should take the app-specific password.

Jun 30, 2015 1:01 PM in response to enteq

I completely agree with the whole two step verification and app generating passwords feature being confusing. I also like to add that, because it is confusing and not clear to the user, it becomes an annoying feature. This means that it is not secure anymore. I seriously hope that Apple understands that people are the weakest link in the security chain. So, make it as clear as possible to the user what they need to do and for what. Help the people in making it more secure, not by bothering them with messages that they have to interpet them selfs. That always leeds to errors.

Jul 21, 2015 5:04 AM in response to iDeMi

This is really just commiseration, not a solution - apologies!


Perhaps I am missing something, but what exactly is the point of enabling 2FA and then generating "1FA" passwords to access the services?


The whole point should be that each device gets a device and user specific, cryptographically strong access key when the user first authenticates the service using 2FA and then the device does not require another user authentication, unless the user wants to type in the password + key code each time they use Mail or iMessage or Facetime.


Having "app-specific passwords" is exactly the same as having passwords. All passwords are "app" or rather, service specific, if I choose to set different passwords... This is fundamentally wrong, i.e., the design itself is wrong. It is basically password authentication made a lot harder for the users.


Regards,


Tamas


PS. It was suggested to write to feedback - but that is not public. I have serious doubts that any of my previous feedbacks were ever read or thought about... Of course, being just a user, makes those unimportant, so I know my place! :-) That is why I would rather let the public see.

Jul 21, 2015 5:22 AM in response to Hoping For a Better Apple

This is a potential solution:


If OS X is asking for Messages and Facetime passwords and then tells you that you need to create an app-specific password, the following may help:


  1. Completely delete the iCloud account from the computer.
    I am not using Photo or iCloud drive and this may have severe implications there, so be careful...
  2. Restart
  3. Add the iCloud account back to the computer.
    At this time, 2FA is executed and apparently those access keys are also properly generated.


Hope this helps...


Tamas

Jul 22, 2015 5:12 PM in response to Hoping For a Better Apple

Hoping For a Better Apple wrote:


Perhaps I am missing something, but what exactly is the point of enabling 2FA and then generating "1FA" passwords to access the services?


If I understand correctly, the point is that a user's primary password is chosen by them, and users cannot be trusted to choose strong passwords (very few people use credential manager apps that generate passwords for them), so 2FA mitigates against the weakness of the user's self-chosen password by requiring a second factor.


App-specific passwords are not chosen by users; they are machine-generated hence much stronger, and they don't need to be remembered, stored or written down by the user - so arguably they don't require the same mitigations.


Additionally, app-specific passwords are used in scenarios where they are cached by one piece of software to talk to another piece of software (e.g. an app talking to a back-end service), and they're subsequently used without human interaction, so a second factor could not be supplied anyway without degrading the user experience.

The whole point should be that each device gets a device and user specific, cryptographically strong access key when the user first authenticates the service using 2FA and then the device does not require another user authentication, unless the user wants to type in the password + key code each time they use Mail or iMessage or Facetime.


... yes, but thats kinda what app-specific passwords are anyway, aren't they?


The only difference is that app-specific passwords are used in scenarios where - for whatever reason - the back-end service only works with 1FA. That might be because the app and the service are owned by a different companies (e.g. the iOS Mail app talking to the Google Mail service), or the service uses a protocol that only supports 1FA (e.g. HTTP Basic Auth), or it's a legacy service that was just written like that.


Since the service expects a password, the user needs to perform the one-off step of 2FA authenticating to a service which generates the app-specific password, and then copy-and-paste that into the app in question, which will subsequently cache it. It must be a one-off step because the app-specific password is not human-memorable, and if I understand correctly the user is not meant to write it down, store it, or otherwise handle it again.


I agree with you that with a modern app, especially if the app and service are written by the same company (e.g. FaceTime app talking to FaceTime service), it should generate the credential automatically so that it's totally transparent to the user. Nothing should need to be copied-and-pasted. Most apps using iCloud already work like this I think. I guess iMessage and FaceTime will get there one day...?


But it's harder to imagine how (say) Google could do that with gmail, given there are so many different mail clients using gmail that are not under their control. So I wouldn't expect app-specific passwords to disappear from the face of the earth anytime soon.

This is a potential solution


But I already found a solution - see the end of my first post. I don't see why your solution improves on that.


This thread was really just a rant at how bad the user experience was.

Jul 22, 2015 11:27 PM in response to enteq

enteq wrote:

Hoping For a Better Apple wrote:


Perhaps I am missing something, but what exactly is the point of enabling 2FA and then generating "1FA" passwords to access the services?


If I understand correctly, the point is that a user's primary password is chosen by them, and users cannot be trusted to choose strong passwords (very few people use credential manager apps that generate passwords for them), so 2FA mitigates against the weakness of the user's self-chosen password by requiring a second factor.


App-specific passwords are not chosen by users; they are machine-generated hence much stronger, and they don't need to be remembered, stored or written down by the user - so arguably they don't require the same mitigations.


Additionally, app-specific passwords are used in scenarios where they are cached by one piece of software to talk to another piece of software (e.g. an app talking to a back-end service), and they're subsequently used without human interaction, so a second factor could not be supplied anyway without degrading the user experience.


I agree that weak and guessable passwords are one reason why 2FA helps, but there are different and prevalent threats that are also addressed, including keyloggers and losing the devices. As I have always been using strong passwords in the past, I welcomed the 2FA solution, as it would have solved for these two threats as well.


The whole point should be that each device gets a device and user specific, cryptographically strong access key when the user first authenticates the service using 2FA and then the device does not require another user authentication, unless the user wants to type in the password + key code each time they use Mail or iMessage or Facetime.


... yes, but thats kinda what app-specific passwords are anyway, aren't they?


The only difference is that app-specific passwords are used in scenarios where - for whatever reason - the back-end service only works with 1FA. That might be because the app and the service are owned by a different companies (e.g. the iOS Mail app talking to the Google Mail service), or the service uses a protocol that only supports 1FA (e.g. HTTP Basic Auth), or it's a legacy service that was just written like that.


Since the service expects a password, the user needs to perform the one-off step of 2FA authenticating to a service which generates the app-specific password, and then copy-and-paste that into the app in question, which will subsequently cache it. It must be a one-off step because the app-specific password is not human-memorable, and if I understand correctly the user is not meant to write it down, store it, or otherwise handle it again.


I would not agree that app-specific passwords are equivalent to device and service specific ones. In fact, I have tested that app-specific passwords are not app-specfic (Thunderbird, Outlook 2016, multiple machines), they cannot really be, as the servers cannot really test if it is that app which uses them, nor whether it is that machine. In fact, your solution actually confirms that, too.


I agree with you that with a modern app, especially if the app and service are written by the same company (e.g. FaceTime app talking to FaceTime service), it should generate the credential automatically so that it's totally transparent to the user. Nothing should need to be copied-and-pasted. Most apps using iCloud already work like this I think. I guess iMessage and FaceTime will get there one day...?

[...]

This is a potential solution


But I already found a solution - see the end of my first post. I don't see why your solution improves on that.


This thread was really just a rant at how bad the user experience was.


Several points:


Firstly, I was ranting too! :-) In fact, I was and still am agreeing with the frustration!


Secondly, the difference, which I consider significant, is that with my "solution" there are no app-specific passwords. Facetime and iMessage "have already got there" - this whole requirement for app-specific passwords is not a problem with the apps, but the outcome of a botched transition from 1FA to 2FA. Sorry for not highlighting this.


After the removal and re-addition of the complete iCloud account on iPhones and Macs, the apps no longer require an app-specific password.


Whilst I agree that the generated passwords are strong, I don't want those to be stored anywhere, I much prefer the machine specific keys that enable revocation by machine and device, rather than the password that may be used in many places. Also, with the app-specific passwords, if those are lost or successfully stolen, one would only get an e-mail after a new device starts to use it - by which time it is too late, the data would have been copied. With 2FA, an explicit authorisation is required when new devices are added and by avoiding the app-specific passwords altogether, unauthorised access is prevented, not just identified after the fact.


Going back to the first point - the user experience is still terrible... Why is this not explained in the Apple help...? And removing and re-adding accounts on several devices? Seriously... At least once done, they are up to date and good to go until the next botched security model change!

Jul 24, 2015 3:35 PM in response to Hoping For a Better Apple

Right, but in your original post you said there is no difference between app-specific passwords and having a 1FA account, and asked if using app-specific passwords defeats the purpose of enabling 2FA:

Perhaps I am missing something, but what exactly is the point of enabling 2FA and then generating "1FA" passwords to access the services?

Having "app-specific passwords" is exactly the same as having passwords.


I replied to answer your question, stating how they are different:

  • a 1FA account relies on a user-chosen password (which means it will typically be weak), and the user is expected to remember that password, and will be challenged to enter it multiple times
  • app-specific passwords are machine-generated (hence typically stronger), the user is not expected to remember them, and handling them is a one-off


...and therefore, using app-specific passwords does not defeat the purpose of enabling 2FA on your account. There are specific threats - such as an attacker guessing the user's self-chosen, weak 1FA password - which are prevented for users who've enabled 2FA, even if they've set up app-specific passwords as well.


I am not saying I like app-specific passwords! And I didn't say they are the same as device/user-specific credentials generated transparently so the user does not have to deal with them; just that it seems to me that they effectively play the same role - only app-specific passwords do it in a much more clunky way.


It would appear that app-specific passwords are a kludge - and as you point out, inferior for both security and user experience (I never said they weren't).


So in the end - I think we actually agree!


with my "solution" there are no app-specific passwords. Facetime and iMessage "have already got there" - this whole requirement for app-specific passwords is not a problem with the apps, but the outcome of a botched transition from 1FA to 2FA. Sorry for not highlighting this.


After the removal and re-addition of the complete iCloud account on iPhones and Macs, the apps no longer require an app-specific password.

OK, I had not realized you meant that.

Jul 24, 2015 4:18 PM in response to enteq

Yes, agreed!


Now I have to go back trying to repair Mail: since the new OS X update, which moved email accounts onto Keychain (without asking), Mail lost all mail and tries to add accounts when started as if there were none - even though the accounts are there in System Preferences > Internet Accounts. Oh dear.


Perhaps I should just switch to Thunderbird... And app-specific passwords... ;-)

Aug 8, 2015 6:48 AM in response to enteq

The entire thing is a complete B0lls up! I'm a pretty savvy computer user and understand what this is. Simply, because a lot of our Apple based apps use the iCloud password, if this is hacked then the baddies have access to all of those apps that use is iMessage, FaceTime, iCloud on the web etc. So now we've got a separate password to for each of these apps. Then there is the annoying code we have to use every time we log


Problem is that when we finally enable this feature a non descript dialog box pops up and when we've finally figured out that hey it's not our iCloud password but the cryptic password that's been generated for us and enter it, we have to do it on all our bloody devices we think we're done. Then a few months later the dialog boxes start popping up and we have to do it all again !!!


Simple solution for me just turn it off, not ready for prime time at all and I the hack of iCloud that celebs had was nothing to do with iCloud but just the fact they picked **** poor passwords.

Apr 29, 2016 1:22 AM in response to Hoping For a Better Apple

Hoping For a Better Apple wrote:


This is a potential solution:


If OS X is asking for Messages and Facetime passwords and then tells you that you need to create an app-specific password, the following may help:


  1. Completely delete the iCloud account from the computer.
    ...
  2. Add the iCloud account back to the computer.


Hope this helps...


Tamas

What do you mean by "completely delete the iCloud account" - are we talking about SIGNING OUT/IN?

App-specific passwords confusion

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.