Those who would be frustrated just wont enable it. But it's not as inconvenient as you make it out to be; you still only have to remember one password, since the second is dynamically generated.
It's optional -- you don't have to enable it if you don't want it.
This is a good answer to those who were recently moaning that "anybody who hacks my google account can now push apps to my phone with out a confirmation!"
Quite frankly, I worry quite a bit less about hackers pushing malware to my phone than I do to people hacking into my e-mail.
I'm going to let this shake out for a while and then enable it.
There is no "remembering" involved -- you get the second password from an app on your phone. And you only have to enter this second password once per month (per computer that you access your account from).
I assume you enter the second password once per browser session, not once "per computer." For people who use incognito mode heavily or clear their cookies on shutdown this will mean using the second password every time, but something tells me those people are of the type who want to be using two-factor auth all the time anyway.
Looks like it's currently broken. The article says "You can activate it by hitting the ‘two-step verification’ link on this page[1].", but it's definitely not there.
However, if you go into "Authorizing applications & sites" it has a warning box which says "An application-specific password can only be created when you are signed up for 2-step verification.", with no mention of where or how that can be done.
It'd be nice if this feature allowed me to have secondary passwords for eg google talk. I don't much care for having to hand out my full credentials just to use things like bitlbee/meebo.
Why does the Android app "Google Authenticator" require ZX Barcode Scanner when Google Goggles has a faster barcode scanner built in? Sometimes I just don't understand Google's inability to be consistent. For example, why do Goggles and the Gallery hide the notification bar. Attention to details Google...
The "Barcode Scanner" app is so ubiquitous it seems built in, but I don't think it actually ships. I seem to recall an actual Google Video demoing it as well, but I'm not quite sure.
I'm not sure what you are addressing, no one is debating the merit of this. drivebyacct is referring to other posts in this thread questioning "Where is this option? I don't see it in my account!"
Not necessarily, they may have been reading an older version. Note:
>But today, Google is making things much, much better for those who want it. Update: Google is actually rolling this out over the next few days, so you may not see it quite yet.
And I don't know where to find this "second password page" you speak of. There's no link in my Google account, if that's what you are referring to. How am I to read it?
It'd be nice if i could use my own 2 factor, e.g. if i had a securid or something similar to do. I'm not all that excited to have to open my phone to get to an app to get my passcode out.
I've been doing this with PayPal and their free security token fob for three years and I couldn't be happier. This kind of thing should be the standard for any 'critical' accounts like banking and email. If you don't have a token you probably have a cell phone anyway.
My largest worry is that coupled with Google's infamous lack of customer support, it might be very difficult to get into your account should something happen to your phone. I know it's something of a pain to have an authenticator removed in World of Warcraft if you lose it or it breaks, but at least there you have a phone number you can call that will let you eventually talk to a human being.
Does anyone know what Google's plan is for lost/broken authenticators?
If you don't have the OTP codes and didn't set up a backup, and can't access any computer/device where you have access from logging in during the past 30 days:
3) You'll need to fill out an account recovery form to verify ownership of the account. Take time to answer each question to the best of your ability. The form was designed to ensure that no one can gain access to your account except you. Since Google doesn't collect a lot of information about you when you sign up for an account, we will ask you questions like when you created your account, what Google services you use, and who you email frequently (if you use Gmail) to make certain you are authorized to access your account.
Same here; that's why I forwarded the oldest email in my account to another address, took note of the date on it, and saved it to my hard drive; headers intact.
Keep in mind each fallback/recovery option like secret question, secondary email address, OTPs etc. is an extra attack vector too. So would be good idea to store that old email somewhere securely too...
I've been called on a few occasions to recover the gmail accounts of family and friends and it hasn't worked once, even when supplying reasonably accurate data.
> 1) When you activate the service, you get a list of ten OTP codes that you should print and store in a safe place.
The main problem with having a list of randomly generated OTP codes is, it very obviously looks like a list of randomly generated OTP codes!
A far better approach is to use the lines of a poem, prayer or even a list of motivational slogans or a grocery shopping list. You can even get more tricky with things like not using the first character or word of the lines. You always need to assume your list of OTP's will fall into the wrong hands, so your list should be protected by at least obfuscation and plausible deniability.
99.9% of the time you aren't worried about someone getting your wallet and taking your password - You are worried about people phishing you, snooping, or otherwise cracking your password.
You'll get a lot more bang for your buck defending against the high-probability attacks then being concerned about the theoretical, but highly unlikely vectors.
Hey Matt, seeing your comments on this post reminded me I wanted to say thanks for making so many comments here on HN. It's awesome to hear from someone directly at Google in your role. Very cool. I'm sure a lot of us think very highly of the work you all do at Google. You and Apple, really, kick ass in this industry.
It's not clear from that page, is there any limitation on the powers of the application-specific password? While it's less likely, if one of those passwords gets stolen can your entire account still be accessed including your account settings?
On Android, the device specific password is used for your phone's Google Account. Which means once you set it up, all Google apps like Gmail, GReader, Talk, Market, etc. will work as usual.
If you suspect your device password is compromised, you can revoke it from your Google account settings in a regular browser.
Great going, google! Banks have been using those RSA dongle thingies for a long time. Now with mobile phones that isolate one app from another, who needs em! And you get OTP codes just in case. Nice.
Instead of a fake login page with 2 boxes, a phisher could just create a fake login page with 3 boxes and pass the keycode along with everything else.
The only increased difficulty in phishing, is if the user notes they're seeing a keycode prompt, decides that they probably shouldn't have to enter that again and doesn't just key it in anyway.
When we're talking about people who fall for phishing scams, does that sound all that likely? I mean, these people have a history of ignoring red flags and being blissfully ignorant to what should even raise a red flag.
Now, what two-factor will help mitigate, is casual sniffing, keylogging, shoulder-surfing and saved password cracking.
While I have used this kind of authentication before, I'm not intimately familiar with it. From the way Kincaid described it in the article, it seems the key is unique only to a general moment in time, not each log-in attempt (though it wouldn't be hard to imagine it being invalidated as soon as it was used).
If it is only a moment in time, I assume the phishing script could simply log in at the same time and hope the user has the "once per computer" setting enabled. Though this seems like too big of something to miss. Can anyone offer some clarification?
Is this a stand-alone fob-style system, where the keycode is unique to a point in time with no knowledge of the connection? Or is this some sort of second-channel verification, where the requesting connection is hashed into the one-time-pad?
Unless I'm missing something, RFC 4226 sounds like the RSA SecurID system I've worked with before; which is essentially equivalent to Blizzard's system for World of Warcraft.
In which case, my criticism stands. It's trivially more difficult to phish a keycode and the limited window of opportunity is simply a non-issue.[1]
Unless Google is calculating a one-time pad based on the individual login attempt and sending it along a second channel to the registered user, there'll be almost no reduction in phishing.
[1] The tens of seconds a keycode is valid are more than enough to establish a connection.
Which means you phished it once. Which means you need to take drastic actions to exploit it, a slow buildup over time is not an option.
Which in turn means you're more likely to get detected. It's not full protection - you'd still need a second channel for that - but it's better than nothing.
For the systems I log in to, each SecurID code is only valid once. If you want to log in again, you need to wait until a new code is available and use it.
As I understand it, you need a secure & clean initial set-up, after which the user should not have to enter a key again as the handshake between your machine and Google will automatically change.
Phishing won't work if the user does not have to enter the key again. It requires a clean (no keylogger etc) initial setup. Once installed if someone phishes the end user wouldn't need to re-enter a key, thus defeating the phishing scheme.
It is important to distinguish between active and passive attacks.
The verification code generated is valid only for a very short time - so unless the hacker phishes the code, and uses it within 10s of seconds, the code is not valid.
Nothing's stopping the phishing site from going and logging in once the token's phished, and logging the cookie as opposed to just logging the password+token.
And you get a lot more seconds if you log in within those 10 seconds.
Is anyone else concerned that Google is now basically forcing this on us, so it can build a database of not only our online history, contact info, etc... but now linking it to a real-life phone number? Think of what the NSA could do with data like that.
Not to mention the whole MAC address collection they did with the Streetview cams as well (allowing them to tie a MAC address and/or IP with a GPS coordinate)
I'm prepared for the down-votes on this one, but it's something to think about.
If you don't want this feature, don't opt in--it's not required. I love that I don't need to worry as much about people trying to hack my Gmail account.
Sure but they're going to ask me about it every time I log in until kingdom come. And there are a lot of users who will do it blindly unaware of the consequences that come with linking your online persona to a phone number.
Authentication code is computed. A phone number is for those who cannot compute it themselves (so Google will perform the computation and give you the result over the phone).
[I think it's really sad that a well-thought-out and well-intentioned non-trolling comment such as yours is downvoted. Especially that you could predict it so easily in advance.]
I went to set up a gmail account the other day for testing out an online game for one of my kids. It wanted to "verify" me with a real-life phone call.
So I just went over to hotmail and set up an account there instead. Sort of a blast from the past, but it was relatively painless.
Email spammers try to open massive amounts of webmail accounts and then exploit those accounts to send tons of email spam. Do a search like [gmail accounts in bulk] to see people trying to spam the Gmail sign-up process. Things like a real-life phone call or phone number/SMS add friction and make it harder for spammers.
It would be so cool if Google could engineer that process the other way around. Instead of me giving Google my number, why can I not dial into a phone number of Google (with my own number hidden). I think that would a) get more friction you need against the spammers and b) retain my privacy (at the cost of a phone call).
Ugh, this is why I don't use facebook. I'm tired of big websites adding these extra "security features" to make it that much easier to track me while adding friction to your site experience.
I'll be impressed if this actually works. Google can't even figure out how to authenticate half of their services off of your google apps domain account.
This wouldn't work for me. I own a mobile phone, but I only use it for specific purposes and don't carry it around with me routinely. Mobile phones are not something that I care about to any significant extent.
Tried it, and now regretting it. I log in with 6 devices, and the idea that I'll have to go through re-authenticating them each month isn't fun.
Each re-auth requires a fresh code from the app.
I access google apps via Safari because Apple's mail app has no real search function. Since the codes expire in 60 seconds, I'm on a timer for writing it down, launching safari, refreshing to get the "login failed" screen, entering in my username and password without errors and then entering in my code. Totally doable, but irritating. Imagine you're in a hurry, and checking your email as you walk down the street. You open your client and instead of your email you get an error. The error doesn't tell you what's wrong, it just says there's a problem with your login. Hopefully you remember that 30 days ago you reset your token, and that's the problem. Now you can pause everything else, and setup your email.
Don't have a pen to write down your code while you switch apps? How's your memory?
I totally get that good security involves expiration dates, but I want things that "just work", not that "usually work".
In principle it's a great idea, and if I could choose how often it expires I'd be a happy camper.
In the Android app you can long-press the generated code to open a context menu to copy the code into the clipboard. I'm not sure if the iPhone can support something similar, but I'll ask the developer.
On the other hand, the Android GMail app is so good that there's no reason to use the web version. So just setup your phone with a device specific password and you are good to go!
I'm able to start the login process in Safari on my iPhone and when I get to the prompt for the one-time code, switch to the Authenticator app, double click on the number to get the copy icon, then switch back to Safari and paste it.
I can see why everyone is so happy, but something to note is the erosion of privacy. You you wont be able to use a gmail account without a phone.
In countries(China) where you need your id to get even a prepay phone there will no longer be any anominity.
Top this off with the fact that google doesn't say how often or if at all whether they give information to the chinese government because its against the law in China for them to say so.
State secrecy and all.
I personally think this should be optional and not mandatory. Otherwise I will stop using all of googles account services.
It is optional! Personally I'd rather the second factor was a little more dependable, the 2nd factor for my LastPass account is a lookup grid. That piece of paper in my wallet is unlikely to run out of battery power or otherwise malfunction, and doesn't have the potential privacy issues you highlighted.
I've been using this on my Gmail account for a couple months in beta. (It was also available for Google Apps Premier/Education/Gov).
Surprisingly it hasn't been a hassle at all-- anyone who uses their Gmail for "everything" should start using it.
It takes 15 minutes to set up (you have to / should generate tokens for each of your mobile and desktop apps, e.g. Apple Mail, iCal, Adium, Meebo, Voice, Latitude) but after that, it's super easy as long as you always have your smartphone+authenticator with you.
Spending 30 seconds extra/month/device to enter a 6-digit keycode isn't a huge price to pay for better security (at least for me-- I have one phone and one computer.)
I haven't tried it, but I don't like being bothered with extra stuff, I can't even imagine my mother dealing with this stuff.
If we can't simplify our users lives, we have failed. Is security hard? Hell it is. But we can do better and we MUST do better, for the love of science.
First, this is optional, so no one who doesn't want it has to worry about it. If you aren't worried about your google account being hacked, then don't enable it.
Second, can you really think of a better option? Two factor authentication like this has been used by high security institutions for years and it works quite well. Personally, it has bothered me for years that my bank does not use 2-factor identification to log in... I am certain there is plenty of room for improvement, but it is certainly non-trivial.
This would seem to be a good thing to offer if you were a company that had any form of customer service.
If I were to lose the little thingy that lets me into my bank account, I can walk into a bank, verify myself, and get another one sent out. Simple and effective.
Can you imagine the process that you'll have to go through to get back into your GMail account after losing your phone?
Considering that you can be an AdWords customer giving them ten thousand dollars a year and still receive nothing but computer-generated form letters in response to questions about your account, I think I'll pass on this one.
95 comments
[ 2.8 ms ] story [ 128 ms ] threadThis is a good answer to those who were recently moaning that "anybody who hacks my google account can now push apps to my phone with out a confirmation!"
Quite frankly, I worry quite a bit less about hackers pushing malware to my phone than I do to people hacking into my e-mail.
I'm going to let this shake out for a while and then enable it.
However, if you go into "Authorizing applications & sites" it has a warning box which says "An application-specific password can only be created when you are signed up for 2-step verification.", with no mention of where or how that can be done.
It'd be nice if this feature allowed me to have secondary passwords for eg google talk. I don't much care for having to hand out my full credentials just to use things like bitlbee/meebo.
[1] https://www.google.com/accounts/ManageAccount
http://googleblog.blogspot.com/2011/02/advanced-sign-in-secu...
>Update: Google is actually rolling this out over the next few days, so you may not see it quite yet.
Do you mean it's built into something like the Camera app?
Not sure how to make that sentence more straight forward.
>Over the next few days, you'll see a new link on your Account Settings page that looks like this:
Yes, it's not available yet. And the second password page is very clear about what it's used for. Reading people, it helps a lot.
>But today, Google is making things much, much better for those who want it. Update: Google is actually rolling this out over the next few days, so you may not see it quite yet.
And I don't know where to find this "second password page" you speak of. There's no link in my Google account, if that's what you are referring to. How am I to read it?
https://cms.paypal.com/cgi-bin/marketingweb?cmd=_render-cont...
Or is there a free one available by other means?
https://idprotect.verisign.com/wheretouse.v
Does anyone know what Google's plan is for lost/broken authenticators?
1) When you activate the service, you get a list of ten OTP codes that you should print and store in a safe place.
2) You can set up a backup phone in case your primary is lost/stolen/fails. There is a voice option, so this number does not have to accept SMS.
If you don't have the OTP codes and didn't set up a backup, and can't access any computer/device where you have access from logging in during the past 30 days:
3) You'll need to fill out an account recovery form to verify ownership of the account. Take time to answer each question to the best of your ability. The form was designed to ensure that no one can gain access to your account except you. Since Google doesn't collect a lot of information about you when you sign up for an account, we will ask you questions like when you created your account, what Google services you use, and who you email frequently (if you use Gmail) to make certain you are authorized to access your account.
I really don't trust it.
The main problem with having a list of randomly generated OTP codes is, it very obviously looks like a list of randomly generated OTP codes!
A far better approach is to use the lines of a poem, prayer or even a list of motivational slogans or a grocery shopping list. You can even get more tricky with things like not using the first character or word of the lines. You always need to assume your list of OTP's will fall into the wrong hands, so your list should be protected by at least obfuscation and plausible deniability.
You'll get a lot more bang for your buck defending against the high-probability attacks then being concerned about the theoretical, but highly unlikely vectors.
Definitely a good idea, though. Losing control of your email is the first step towards losing control of all your other online accounts.
Because if not, this is pretty awesome.
(Disclaimer: I worked on the Android app.)
If you suspect your device password is compromised, you can revoke it from your Google account settings in a regular browser.
Now I wish my bank would do this.
Instead of a fake login page with 2 boxes, a phisher could just create a fake login page with 3 boxes and pass the keycode along with everything else.
The only increased difficulty in phishing, is if the user notes they're seeing a keycode prompt, decides that they probably shouldn't have to enter that again and doesn't just key it in anyway.
When we're talking about people who fall for phishing scams, does that sound all that likely? I mean, these people have a history of ignoring red flags and being blissfully ignorant to what should even raise a red flag.
Now, what two-factor will help mitigate, is casual sniffing, keylogging, shoulder-surfing and saved password cracking.
If it is only a moment in time, I assume the phishing script could simply log in at the same time and hope the user has the "once per computer" setting enabled. Though this seems like too big of something to miss. Can anyone offer some clarification?
Of course, paypal's "I lost my authenticator, log me in anyways" button is kind of defeating the purpose...
Unless I'm missing something, RFC 4226 sounds like the RSA SecurID system I've worked with before; which is essentially equivalent to Blizzard's system for World of Warcraft.
In which case, my criticism stands. It's trivially more difficult to phish a keycode and the limited window of opportunity is simply a non-issue.[1]
Unless Google is calculating a one-time pad based on the individual login attempt and sending it along a second channel to the registered user, there'll be almost no reduction in phishing.
[1] The tens of seconds a keycode is valid are more than enough to establish a connection.
Which in turn means you're more likely to get detected. It's not full protection - you'd still need a second channel for that - but it's better than nothing.
It does many good things. That is not one of them.
You can download the Google Authenticator app.
These algorithms are known. You can implement it yourself if you wanted to.
Phishing won't work if the user does not have to enter the key again. It requires a clean (no keylogger etc) initial setup. Once installed if someone phishes the end user wouldn't need to re-enter a key, thus defeating the phishing scheme.
The verification code generated is valid only for a very short time - so unless the hacker phishes the code, and uses it within 10s of seconds, the code is not valid.
And you get a lot more seconds if you log in within those 10 seconds.
Not to mention the whole MAC address collection they did with the Streetview cams as well (allowing them to tie a MAC address and/or IP with a GPS coordinate)
I'm prepared for the down-votes on this one, but it's something to think about.
I went to set up a gmail account the other day for testing out an online game for one of my kids. It wanted to "verify" me with a real-life phone call.
So I just went over to hotmail and set up an account there instead. Sort of a blast from the past, but it was relatively painless.
I'll be impressed if this actually works. Google can't even figure out how to authenticate half of their services off of your google apps domain account.
I did finally give in the other day and got a Nexus S. I've even talked on it a few times.
Each re-auth requires a fresh code from the app.
I access google apps via Safari because Apple's mail app has no real search function. Since the codes expire in 60 seconds, I'm on a timer for writing it down, launching safari, refreshing to get the "login failed" screen, entering in my username and password without errors and then entering in my code. Totally doable, but irritating. Imagine you're in a hurry, and checking your email as you walk down the street. You open your client and instead of your email you get an error. The error doesn't tell you what's wrong, it just says there's a problem with your login. Hopefully you remember that 30 days ago you reset your token, and that's the problem. Now you can pause everything else, and setup your email.
Don't have a pen to write down your code while you switch apps? How's your memory?
I totally get that good security involves expiration dates, but I want things that "just work", not that "usually work".
In principle it's a great idea, and if I could choose how often it expires I'd be a happy camper.
</rant>
In the Android app you can long-press the generated code to open a context menu to copy the code into the clipboard. I'm not sure if the iPhone can support something similar, but I'll ask the developer.
In countries(China) where you need your id to get even a prepay phone there will no longer be any anominity.
Top this off with the fact that google doesn't say how often or if at all whether they give information to the chinese government because its against the law in China for them to say so.
State secrecy and all.
I personally think this should be optional and not mandatory. Otherwise I will stop using all of googles account services.
Surprisingly it hasn't been a hassle at all-- anyone who uses their Gmail for "everything" should start using it.
It takes 15 minutes to set up (you have to / should generate tokens for each of your mobile and desktop apps, e.g. Apple Mail, iCal, Adium, Meebo, Voice, Latitude) but after that, it's super easy as long as you always have your smartphone+authenticator with you.
Spending 30 seconds extra/month/device to enter a 6-digit keycode isn't a huge price to pay for better security (at least for me-- I have one phone and one computer.)
If we can't simplify our users lives, we have failed. Is security hard? Hell it is. But we can do better and we MUST do better, for the love of science.
Second, can you really think of a better option? Two factor authentication like this has been used by high security institutions for years and it works quite well. Personally, it has bothered me for years that my bank does not use 2-factor identification to log in... I am certain there is plenty of room for improvement, but it is certainly non-trivial.
I suppose this is what I get for being both a hacker and a luddite.
But this definitely will NOT work for me.
If I were to lose the little thingy that lets me into my bank account, I can walk into a bank, verify myself, and get another one sent out. Simple and effective.
Can you imagine the process that you'll have to go through to get back into your GMail account after losing your phone?
Considering that you can be an AdWords customer giving them ten thousand dollars a year and still receive nothing but computer-generated form letters in response to questions about your account, I think I'll pass on this one.