Apple Adds Two-Step Verification to iCloud and Apple ID
appleid.apple.com
appleid.apple.com
Setting up "trusted devices" (iPhone, iPad, etc.) works really well: Apple already knows which devices you own, so all you have to do is select the device and you get an instant push notification to unlock to see the verification code.
Apple gives you a backup recovery code with very clear instructions to print/write it somewhere safe. They require you to re-enter it as part of the setup process to make sure you got it right.
When you need a code, you pick the device you want it sent to and Apple pushes it out instantly via some feature baked into iOS. You can also set up any phone to have a code delivered via SMS, but presumably this is less secure because it could be read even if your phone is locked.
Overall this is a great experience for the user -- much more friendly than Google Authenticator.
In fact I wish this process was open a la Google Authenticator so that other applications could use it (this will happen when hell freezes over).
What if you're actually logging in with the iDevice, does it just automatically allow it without asking?
Exactly. I have so many things in Google Authenticator that I have to scroll. The timer is also annoying -- sometimes you have to wait for a few seconds for the codes to refresh so you have enough time to type in the code.
> Can you still manually get a code, in case you lack network (& don't want to break out the backup code)?
No, but for Apple you don't need to do this because you only need the code if you're accessing their website so you have to have internet access. I don't think I ever use the Google Authenticator without internet access.
> What if you're actually logging in with the iDevice, does it just automatically allow it without asking?
No idea.
> No, but for Apple you don't need to do this because you only need the code if you're accessing their website so you have to have internet access. I don't think I ever use the Google Authenticator without internet access.
At work, I have no cell service but can still use my laptop. I don't want to use their wifi with my phone due to proxy server setup hassles. So I think it's still a valid use case.
Now, Google does have a good seemingly automated recovery service (you need to share a lot about your account to prove you're you but it works) - I'd rather not have reason to use it, though.
First: A large number of Google's web applications still rely on application specific passwords. This was understandable a year or so ago, but still? It's getting very tiring generating an application specific password for some Google applications.
This brings me to my next point: the use of application specific passwords has been made complicated than what's required. When confronted with a page that asks me for an application specific password, it takes too long to navigate to the correct page so that I can generate an application specific password.
Thirdly, I can't change the name that I give to an application specific password. Discovered that you have a new installation of Chrome on a VM and want to create a password for that? Too bad: you can't rename the existing password so that you can distinguish the two easily.
Lastly: Have you checked out the mess that's the management page for it? It's extremely confronting. It takes a bit of getting used to. In-fact, until very recently it was rather buggy. For instance: the page used to have a date which showed when an application specific password was last used. This date always had the year 1970. Who lets these kind of bugs through??
Can't see any easy way to change my language on the page. How annoying!
And, as it's stated in the FAQ [1], SMS option is only available in those countries at the moment, regardless of where you're located. When it becomes available in Poland, they'll text you and you can activate it. But until then, you can safely use 2FA without an SMS backup (as I did).
Now, I know that technically the area code for ALL mobile phone numbers is 04, so I split that up. Nope, SMS never arrives. Next I removed the leading zero from the area code so it would be formatted as +61 4 xxxx xxxx.
Those who are familiar with Telcos and the way phone numbers work internationally would eventually stumble onto the right solution. Still pretty shocking though.
Apple passwords have a max length of 32 characters.
Unfortunately, the change password page doesn't enforce this limit and will blissfully let you think you've changed your password to something that has 50 characters, but actually only stores 32.
Later, when you use a Password Manager that saved the full 50 characters, suddenly your password doesn't work.
Some Apple pages' login password fields cut off automatically at 32, which lets the pasted password work (as you can't paste more than 32), but this is not the case within iTunes itself or on the iPhone.
Solution: Apple needs to limit the new password entry fields on the My Apple ID -> Password and Security page to 32 characters. Or, alternatively, accept and store longer passwords. (as 32 characters is a bit tight if you're using a passphrase)
1) I had to switch my password to something more "secure". That means adding a capital letter and a number. I am sick and tired of companies forcing me to use non-memorable passwords that have less entropy than if I had come up with something memorable, personal and long by myself.
2) "You must wait 3 days to enable two-step verification. This waiting period helps ensure that no one other than the owner of this Apple ID can set up two-step verification. A notification email will be sent to all addresses we have on file. Thank you for your patience."
Regardless of the reasoning for having this in place, all it does is make for a more difficult user experience. Currently when I signed into my Apple ID today, Apple didn't have this process in place and assumed that it was me signing in. So by asking me to change my password when I want to enable this feature it should probably be assumed that I am the account holder. If I was in fact an attacker, changing the password on my account, what if I was on holiday for a week? What if that email hit my spam folder? What if I just didn't notice the email because I am one of the many millions of people who fight inbox zero daily?
EDIT: Furthermore, this has now broken my iMessage and Facetime, with Apple not sending a new activation to my device so I can use these services.
From http://support.apple.com/kb/HT5570
"As a basic security measure, Apple does not allow two-step verification setup to proceed if any significant changes have recently been made to your account information. Significant changes can include a password reset or new security questions. This waiting period helps Apple ensure that you are the only person accessing or modifying your account. While you are in this waiting period, you can continue using your account as usual with all Apple services and stores."
Contrast to someone getting your phone today... they can easily determine your iCloud account name in Settings, and then send a password reset for it that is delivered to the unprotected Mail app.
So for most people, it's certainly more secure.
I think they do a pretty good job of emphasizing that there are three things involved here: Recovery Key, password, any trusted device. Any two will allow you to recover the third (except if you lose your phone). Not having any two and you lose your ID forever.
Nothing on the linked page, nothing in my account settings... so I have no idea how this works.
EDIT: never mind, it's completely hidden behind "Password and Security" in your account, and then you have to answer your security questions to even SEE what things you can do. ARGH. It took me several tries -- security questions should NEVER be character-matched. How am I supposed to remember if I typed in "Mike" or "Michael" or "Crazy Mike" for my childhood best friend, or "Honda" or "Accord" or "Honda Accord" for my first car? (Those are obviously not my actual answers). Security questions should ONLY ever be "matched" by a human operator over the phone. And God forbid you should ever mistype your initial answers! There's ZERO warning that these will ever be used in a "password"-style sense. </rant>
~ http://9to5mac.com/2013/03/21/apple-beefs-up-icloud-apple-id...
So the answer is no; the strength measurement would be done on the server when the password is being hashed or verified.
I don't think it adds much security though. If you don't trust the channel to properly protect the transmitted password, it's not possible to build a trusted relationship with the server. You have to assume ssl works.