Great to see this as finally an option, interesting that there is a 3 day wait to activate it though...just to be certain it is my identity that wants to add it.
"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."
The process forced me to update my password to use their new password requirements which then forced me to wait 3 days. I'm pretty sure my old password was secure but it didn't meet all of the new standards. Kind of annoying.
I encountered the same. After struggling with the security questions I set new ones. Then, when enabled two-step auth, they tell you you'll never need the security questions again. drat
Really happy to finally have this option, but disappointing that there isn't (yet) a way to generate codes from your trusted device as with Google Authenticator. Hopefully it's on the way.
There's nothing either for me. And I'm in the US, in the heart of Manhattan, using my Time Warner cable.
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>
I'm not a fan of security questions as they're easily discoverable and known to other sites that ask the same question. So I just enter random nonsense words and save a screenshot in a secure store.
To what extend is it two factor when one of the factors is the device you are working on?
One of the biggest risks I see with iCloud is someone finding/stealing my phone, and using it to erase other devices. A code send to my phone won't prevent that.
For online services, a code to your phone makes lots of sense (something you have part). For phone services, I'm less sure.
To use the code sent to the phone, you need to know the password or the recovery key as well. That's the two factor part.
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.
No, the FAQ says: You can reset your password at My Apple ID by using your Recovery Key and one of your trusted devices.
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.
Apple has done a great job walking users through this process.
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).
Google's approach is more unix-y - it lets you shoot yourself in the foot. Requiring you to put your recovery code back in at least forces people to memorize or write it down.
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.
I haven't used Apple's system, so I can't comment on it. However, Google's system has a few gaping holes that make it far from effective from a usability standpoint.
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??
1) Yes, Google should move more of their apps to supporting this, but looking at only Google services is missing the point. Google Authenticator's TOPA is based on an open standard, so any third party can work with it too (and many do,Dropbox, Lastpass, Drupal, App.net, Dreamhost..."
3) I haven't run in to this problem, but as you can imagine, NOT being able to change it provides a number of benefits from a security standpoint, and if you do want to change it, it is just a matter of creating a new one and deleting the old one. I should think that'd be good enough for anyone.
Why do you find this more friendly than Google Authenticator? Just because it pushes rather than requiring the user to open an app? Can you still manually get a code, in case you lack network (& don't want to break out the backup code)?
What if you're actually logging in with the iDevice, does it just automatically allow it without asking?
> Why do you find this more friendly than Google Authenticator? Just because it pushes rather than requiring the user to open an app?
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, 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.
Argh! Incredibly annoying edge case! I'm in Poland, but have all my language settings set to English, and the only country codes for receiving SMSs are those of English-speaking countries!
Can't see any easy way to change my language on the page. How annoying!
It's annoying, but isn't an edge case. Lots of people use US stores (because it has more content) and gift cards.
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).
Yeah, they havent done a good job of localising this. In Australia it asks for an 'area code' as well has my phone number for my mobile phone. How can a MOBILE phone have an area code (in Australia, area codes are per state).
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.
"Initially, two-step verification is being offered in the U.S., UK, Australia, Ireland, and New Zealand. Additional countries will be added over time."
Not in Germany yet.
I just attempted to add two-step, and Apple told me I needed a stronger password before continuing. How do they know my password strength if it is salted+hashed properly?
So you mean that the strength measurement is send from the client to the server alongside with the hash+salted password? Password are hashed+salted on the client side right? They're not transmitting password "in the clear" to hash+salt them on the server side? (even on SSL I'd be worried about passwords travelling between client/Apple-severs seen the number of hacks trying to exploit SSL/TLS recently)
That's true only for the initial password creation. During verification you could send down two salts, the real salt and a session salt. You double-hash the password on the client with both salts, and the server hashes on the server with the session salt. The hash that gets sent over the wire cannot be used for replay attacks.
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.
It's kind of sad that it's taken Apple so long to do this, and they've done such a mediocre job of it. Offline verification vs. SMS, taking advantage of the secure element in 3GS+ phones, etc., and supporting credential management for third party sites, all would have made Apple superior to desktops or Android for enterprise use, or high-end consumers. But they did none of that.
wonder if its got to do with credit card fraud on iTunes than any specific sensitive data concern.
Do people use iCloud a lot?
or maybe they are thinking of providing some cloud service this year which needs the added security
What on earth is Apple doing here. The steps I went through so far:
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.
In case anyone else changed their password to something absurdly long only to run into the same trouble I did:
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)
50 comments
[ 2.8 ms ] story [ 109 ms ] threadFrom 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."
~ http://9to5mac.com/2013/03/21/apple-beefs-up-icloud-apple-id...
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>
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.
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).
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??
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.
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).
[1]: http://support.apple.com/kb/HT5570
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.
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.
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.
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)