Myth: But what if my cell phone doesn't have SMS/signal?
Reality: You can install a standalone program called Google Authenticator, so your cell phone doesn't need a signal.
Myth: Okay, but what about if my cell phone runs out of power (added: or my phone is stolen)?
Reality: You can print out a small piece of paper with 10 one-time rescue codes and put that in your wallet.
Myth: Don't I have to fiddle with an extra PIN every time I log in?
Reality: You can tell Google to trust your computer for 30 days and maybe even longer.
Myth: I heard two-factor authentication doesn't work with POP and IMAP?
Reality: You can still use two-factor authentication even with POP and IMAP. You create a special "application-specific password" that your mail client can use instead of your regular password. You can revoke application-specific passwords at any time.
Myth: Okay, but what if I want to verify how secure Google Authenticator is?
I was reluctant to setup two-factor for a long time, perceiving it to be an unnecessary hassle. Then somebody tried to gain access to some of my accounts through my Apple ID. They were unsuccessful (I don't have any common passwords these days so managing to send a password reset to my GMail wasn't terribly helpful) but it certainly made me paranoid enough to switch.
I currently have two-factor setup on two accounts. I won't say there's no hassle involved--authorizing a machine via SMS so that I can login and generate an app-specific password is a chore--but the peace of mind is well worth the hassle.
Did you also know that you can re-assign your Apple ID to an existing e-mail address? Like, say, one you have two-factor enabled for? Now people can socially engineer Apple's flawed policy all day but they'll need to steal my phone, too.
EDIT: Also, if you don't have backups, you might as well just delete everything yourself right now and use that as motivation to prevent the same thing from happening again. Hackers, tornadoes, spontaneous combustion and ghosts are all conspiring to destroy your data sooner or later.
Have you encountered any other sites that allow you to use Google Authenticator to generate OTPs?
Part of the reason I think two-factor authentication is a usability burden is because each "identity provider" wants to use its own protocol. Google uses an Android app. PayPal sent me a card. My brokerage has a keychain token available. Other companies use a "soft" RSA token that runs on Windows. But if everyone agreed on a protocol, then I could have everything in one place, which would make two factor authentication significantly more enjoyable to use. (I know there are standards: the question is, who other than Google follows them? :)
> I believe Google Authenticator is based on open standards
The standards implemented are bonafide RFCs - HOTP (counter-based) was published in 2005, no less. I'm not sure how much lower the barriers for integration could be.
Lastpass also uses Google Authenticator. You can get server-side code so you can use Google Authenticator on your own server, or use it to offer two-factor authentication to a web service you are running. It's an open protocol, with an open source implementation. All you have to use it.
A lot of the tokens(Google Auth included) follow http://www.ietf.org/rfc/rfc4226.txt. Problem is everyone has a different way of provisioning the secure key. Some of which are unsafe (I am looking at you Google Authenticator!. Yes a qrcode is kool idea but theres no guarantee that you are the only one who provisions the key using the image.)
I designed Authy with that in mind. I wanted a way to have a 1 token for all accounts. Maybe we will add support for Google Authenticator, so you could import your Google Auth token into the app.
Meraki (full disclosure: my employer) has two-factor authentication for their network config/admin web interface; whatever the tool used (I haven't worked on that part of our codebase), it is compatible with Google Authenticator.
Not quite the same as two factor auth (almost the opposite in fact), but I was extremely annoyed when gmail started relentlessly asking me to add a backup email address for password resets. Had the author not had an insecure backup email address, this wouldn't have happened either. Of all the passwords I'm likely to forget, gmail ranks near the bottom. The password to login to who knows where to get the gmail recovery email? The top.
That's absolutely true. I was horrified last week when I discovered my Gmail account (with a unique 30-character long password, 2-factor enabled, NEVER used unless on my MacBook at my house) had a "backup" email address to my Yahoo account from 8 years ago, with the nice password '1123581321'. I could've killed myself.
Why do you use the term 'application-specific passwords' although these passwords are not application-specific at all?
They are Google-generated passwords with a user label. And if you use 2-factor authentication, they are the weakest link in the chain since they provide full access to a google account except for access vectors with 2-factor authentication. In addition, every app can use such a password, not just the app you created the password for …
2-factor authentication is great and certainly recommendable but you should not fool users by using the false term 'application-specific passwords'. In addition, more complex Google-generated password would be appreciated.
Also this password doesn't give you full access to your Google account. You cannot log into Google web apps this way (AFAIR). Thus you won't be able to mess with account settings (passwords etc). Before you can change critical account settings Google asks you to provide your traditional password again.
'Application-specific' is IMHO not just a friendly but a misleading name. They are simply not application-specific.
Using one of these so-called application-specific passwords, you can delete calendars, mails and contacts. That is critical enough for most users.
An additional concern is the usual 30-day authorization you give in order to avoid entering your 2-factor token again and again. Is there any way to de-authorize such a 30-day authorization?
Anyway, I don't rule out that my perspective might be too strict. For must users, the whole Google 2-step authentication system is probably a very important step towards improved security.
There's something that bugged me about two-factor the moment I activated it. The application specific passwords are stored in plain-text. How does Google know that it's actually e.g. Chrome accessing my mail with a given application-specific password?
If a hacker gets a hold of an old backup of mine, which includes a Pidgin configuration file I forgot to delete, which holds a plaintext password, can he get into my account with that?
If you didn't revoke the application-specific password. And you should be revoking them when you're no longer using them.
If you weren't using application specific passwords, of course, it would have been your actual Google password in that Pidgin config.
It's a little disappointing that the app-specific password isn't more secure, but it's certainly not less secure than foregoing them.
App-specific passwords are bypasses of 2-factor auth. Use them selectively and with care, revoke ones you're not using anymore. And replace them from time to time.
Two-factor authentication is as secure as you make it.
If you value security more than convenience don't use application specific passwords. Google certainly allows for that by only consuming their services through a secure web interface. Is there another mainstream e-mail provider who supports that?
However, if you would like to use apps, gtalk, pidgin, etc. Google will still let you and it will still be more secure than before (revoke specific passwords, etc.).
If one of your application specific passwords (ASPs) is compromised your e-mail content will be compromised but NOT your account as long as your phone / token generator are under your control, allowing you to recover access by your own means. That is a big difference.
That's exactly why I don't use 2-factor. It's only as secure as a single complex token. I use a password manager with complex passwords. I fail to see the added security of enabling 2-factor in this case.
Since I've been downvoted without a response, let me elaborate on my concerns. I haven't seen the threat of application specific passwords (ASP) addressed properly. If an ASP is sniffed or somehow extracted from a device it seems like it's practically equivalent to a single-factor authentication password. I couldn't determine from Google's docs if an ASP will allow you to change a master password or not. Or if it could be used in the place of a master password. It seems like it can only be used through apps that utilize Google APIs. Does anyone know if one of those APIs allows for changing of the master password?
When you need to make any changes to the 2-factor settings, you must enter your account password and the 2-factor password. The ASP cannot be used for this purpose.
Me too. It seems to me that since ASP allows me POP/IMAP access to a gmail account, it probably gives me enough access to run the "send a password reset" attack. I can't use that to 0wn the two-factor protected google account, but I can easily use it to 0wn the AppleID/Anazon/eBay/PayPal account using the gmail account for the recovery address…
Off the top of my head, I don't even know if it's possible to ensure my iPhone or GalaxySII is using SSL/TLS for it's POP/IMAP connections (or if an attacker with brief access to my device could switch it to plain-text-passwords then sniff it's authentication on the local wifi).
Gmail supports restricting POP/IMAP access to specific labels. Couldn't you set up filters to move password reset emails/all emails from services you care about out to non-POP/IMAP folders, skipping the inbox.
Then we should probably move towards (something like) OAuth in all our apps, be it web, desktop or mobile. This way a potential evildoer is left only with a very limited token. Even more, we can invalidate tokens based on time and device used.
Having OAuth or Two factor in Google Talk/Chrome or any application based login system shouldn't be THAT hard. Along with your password, there should be another text field stating "OTP" or some other friendly name.
2FA is equivalent to changing your password every 30 seconds. Yes, it's "only" as secure as that single token, but the entire point of doing 2FA on a separate hardware device is that even if you have every piece of malware installed on the machine you're logging in to, there is still an analog transfer of information from your phone(/keyfob/whatever) to your computer via your brain. It keeps your "password" in two parts, one of which lives in your head/password manager/muscle memory, and the other of which lives on your phone.
ASPs are certainly less secure than 2FA, but they only permit services access, rather than account administration access.
2FA is slightly more hassle for the knowledge that you are effectively protected against a wide range of attacks. It's very worth it.
That reminds me of discussion on desktop security where often root access is seen as they holy grail – while the potential for damage with simple user access gets ignored …
2-step authentication is great but the (wrongly) so-called application-specific passwords are definitely the weakest link in the chain. They do not allow for a full takeover of a Google Apps account but there is still a lot of damage possible.
Two factor limits the time window within which a password is useful. If one of your complex password's hashes gets exposed, someone would need to also know your ssl-only two factor auth cookie, and then reverse/bruteforce your password within the 30 day window the cookie makes it valid for - that makes the "current model" of releasing the hashes on pastebin and crowdsourcing the hash-cracking much more time critical.
Are you asking if a hacker could use the application-specific password to access your email account? I'm pretty sure the application-specific passwords are only good for the service using them (e.g. the first service to use a newly generated password is the only one allowed to ever use it), but that would be trivial to test for yourself.
That can't work - how would they identify the service using them? Ip address is useless for this purpose and other identifiers ar either not available or very easily spoofed and thus equally useless.
If somebody gets hold of the application specific password, he'llbe able to use said application.
I just used the same password to login to my Talk account in Pidgin and later for my Android. This is really insecure, especially when Pidgin saves passwords in plain text.
You're perfectly welcome to use the same password multiple times-- it's as secure as you yourself make it. When Google generates an App password, it displays it once-- and then trashes it. On that same page is a list of the identifiers you've given all of your apps, and the last time that identifier's password was used to log into your account. At any point, you can trash a generated password, and anything using that password can't log into your account anymore.
If you use the same generated password for every application, then you're not in that much better a situation than you would be otherwise. If you use different identifiers for each application, you can identify exactly where a breach happened from by last login time, and disable that password entirely.
Kind of. This is the reason 2-factor makes me uncomfortable too: instead of having 1 username/1 password, it's actually 1 username/lots of passwords. And the passwords generated are all lowercase alphabetic characters (I assume to make them easier for users who don't/can't copy-paste).
It'd make me a lot more comfortable if I could lock each password down to a specific Google service (for instance: generate an OTP for Pidgin, and enable it only for Google Talk), they were a lot longer, and had special chars + numbers in them.
ASPs are 16 characters. That's 26^16 - 26^15 = 4.19315 * 10^22 (41.9 sextillion!) cominbations. If you aren't confident in the size of that keyspace, I'm not sure what to tell you.
The point about permitting a password to be used for only certain services is absolutely a valid one, though.
You are right and that's what I'm going to do. But it's no less secure until you don't "remember" that token anywhere. A remembered password in Google Talk (desktop client) is just encrypted and can be easily recovered.
Edit: To add to my reply, I have never used the remember password for Pidgin in the past, however enabling 2 step auth require me to do that. It'd be great if Google could somehow allow only the first associated app with a password for subsequent uses. Technically that looks very challenging (if at all possible).
this is crazy, doesn't every current linux distro already have a keychain-like-thingy which is protected by the user password?
Adium (which is also based on libpurple) uses it on the mac, which means there is no plaintext password lying around.
That is not possible with the current 2-factor authentication system. App-specific passwords are only called 'specific', they are not really app-specific, i.e. you can use them with any app you like if 2-factor authentication with a token has not been implemented yet.
The inflexible account ordering in Authenticator is bugging me, since I recently added a 5th account (not 5 google accounts) and my phone only shows 4 at a time. I don't know if you have any influence over the people maintaining the app, but it looks trivial to fix, given the comments.
I was wary to set up 2FA until I learned that you can set it up even without a cellphone or your own computer. You can have the second factor be a voice call, so it can call a landline or dumbphone without an SMS plan. Plus, if you ever lose your phone or cancel your number, you can set up backup phone numbers. I set up my fiancee's phone number as a backup number in case I ever lose my phone.
Someone big got hacked this way recently - the attacker managed to social-engineer a call forwarding change, then used a "landline 2FA auth call" to gain the foothold then needed. (I think it was Cloudflare?)
It's similar to @mat's problem - Amazon assumed the CC last 4 digits was "non identifying", Apple assumed they were.
How much effort do you suppose your phone company expends securing your voicemail or call forwarding? I'll bet it's less than would be considered "industry best practice" for securing your corporate dns records…
First, let me explain a little bit of background on this "hack". From the article, they had 4 problems with their process that allowed them to get hacked badly:
1. AT&T was tricked into redirecting my voicemail to a fraudulent voicemail box;
2. Google's account recovery process was tricked by the fraudulent voicemail box and left an account recovery PIN code that allowed my personal Gmail account to be reset;
3. A flaw in Google's Enterprise Apps account recovery process allowed the hacker to bypass two-factor authentication on my CloudFlare.com address; and
4. CloudFlare BCCing transactional emails to some administrative accounts allowed the hacker to reset the password of a customer once the hacker had gained access to the administrative email account.
I'm not really sure what #3 is and #4 is irrelevant to our discussion, so I'll concentrate on points #1 and #2.
From #1, it follows that the attackers were able to obtain the phone number associated with the two factor auth. How did this work? My assumption is that it was a very targeted attack.
The article starts the attack at June 1st, 2012, but I believe (read: assume) that the attackers probably met the target of the attack beforehand and obtained his/her business card (with a cellphone number), which allowed them to perform #1 above.
So, given that this attack required a physical piece of paper (i.e. a business card) to be acquired from the target, it is not a stretch of imagination to say that if another attacker wanted to obtain the last 4 digits of someone's credit card, all they need to do is follow the person to a restaurant or gas station and get a payment receipt -- every receipt has the last 4 digits written on it. Some have the first four.
Therefore, I don't believe it was Amazon's fault for assuming the last 4 digits are non-identifying, but rather Apple's fault for assuming they are. To be clear, hindsight is 20/20, so I think it was relatively reasonable for Apple to assume that. However, I do expect Apple to change this policy in the future.
I think we're vigorously in agreement here - the last 4 CC digits are certainly not identifying, and I'm perhaps a little less forgiving that you in letting Apple off for thinking so. I'm also not happy with Amazon's assumption that they should be displaying them quite so easily (although at least they don't display them until you're far enough "in" to an account - and it's not easy to work out an alternative way to distinguish between several different CC's when you can have more than one linked to your account).
(And, there are many alternative and easier ways to acquire most people's cellphone number - no need to meet someone or get them to give you a business card… But your point still stands…)
My apologies, I somehow glossed over the Apple part of your post. I agree with everything you said, perhaps even about being forgiving of Apple using the last 4 digits as a verification mechanism.
It's true about a cellphone number -- from what I heard about his attack outside of this article, this a very targeted attack, and the attacker knew exactly what kind of data to expect in the GMail account, which is what led me to conclude that the attacker probably knew or met the victim, but likewise, good point about obtaining the cell in other ways.
See above for Matt Cutt's answer: you can also use a yubikey (a tiny USB device that pretends to be a keyboard, and enters the code when you press a tiny button on top).
I have been using it in Vietnam for over a year without any major problems and I have suggested a few family members (who are not tech savvy at all) to use it too.
The app works very good on both Android and iOS (I personally use the iOS app because I flashed new ROM all the time and sometimes Titanium Backup of the app doesn't work). I tried the SMS a few times, the message normally arrives within one minute.
There seems to be something funky with "application-specific passwords" (ASP) on Chrome. Let me explain the problem (that I documented to a friend ~1 month ago): I just revoked all Google Chrome keys, cleared out all of my history / cookies / passwords / forms, etc.
I went to a different computer that had previously had Chrome synced using ASP, switched to my account, and went to settings. At the top, I get this error message: "Account sign-in details are out of date. Sign in again" That's good since ASP was revoked. But then I go down to advanced settings => passwords, and they're all still visible?!?! That's just WRONG! If the ASP login credentials have been revoked, access to all locally stored passwords need to be revoked too!
Any idea what's going on? This seems like a flaw. The 2-factor authentication is still great though.
The friend was a GOOG employee, but not a member of the Chrome team. Indeed, I should file an official bug report... but the Matt Cutts bug reporting system is usually so much more responsive. ;-)
Myth: Right, but what happens in the very common scenario of my Android phone-- logged into Google with the Authenticator installed-- getting lost / stolen? Surely then 2-factor auth is basically useless?
Reality: You go into Google account security and choose 'Clear the phone info and printable codes' and 'Forget all other trusted computers. Require a verification code the next time I log in from any other computer'.
What are you trying to protect against in this case?
If your phone gets stolen and it's logged in to your google mail without a lockscreen pin/code, then yeah - the thief can read your mail, 2fa won't help. They can also run your Authenticator app and see the current 6 digit number, but that's not useful without the password as well.
(I'm not sure how easy it is to extract the Google password from an Android or i phone - I wonder if you can just switch them to non-TLS POP3 or IMAP and have them send a cleartext password over an unencrypted wifi connection?)
If the phone is rooted(as is the case with mine) then an attacker could change the list of trusted Certificate Authorities on the phone and then perform a MITM attack to get any passwords being passed over the air.
However, I think google services use XMPP if I'm not mistaken. In which case the password is never actually transmitted over the air. XMPP uses Digest access authentication[1]. Short version: the server would first send a challenge to the client. The client hashes the challenge with a hash of the password and returns the result. The server performs the same operation and compares. So even with a MITM you'd get nothing. Furthermore, the client itself would never need to store the password either.
If you have two-factor auth enabled, your Android phone stores a app-specific password -- even if extracted, it wouldn't be terribly useful (assuming you revoke it).
You should be using POP or IMAP only on your phone so that you can revoke permission after it is stolen (when you log in to your account from a desktop and use a backup key from the printout). If you are logged in to your main Google account on your phone you are asking for trouble. While I will be sympathetic after it gets stolen and someone ruins your life, I won't be surprised.
If you regain control of the phone number before someone finds the phone and uses it to seize control of the Google account, you wouldn't lose anything more than the phone.
Sounds like a lot of effort, or at least a lot of things to consider. I wonder how many people were completely locked out of their accounts because they enabled 2-factor auth and didn't do all the right things.
The root problem in this story is that things are just too damn interconnected these days. And we're encourage to interconnect them even further (using cellphones to authenticate email, in this case).
Edit:
I think that my reply is not harsh enough. After reading the comments more closely, I see that this a typical IT response to IT failure. 1. Ignore the root cause. (Interconnectedness.) 2. Blame the user. (Implicitly, for not enabling two-factor auth.) 3. Suggest a workaround and dismiss any concerns real-life scenarios. (E.g. loosing your wallet and cellphone in an emergency. Emergencies like that happen more often that you'd think.) 4. Feel smug.
Although enabling two-factor auth in gmail is great, I still fail to see how it would have protected his iCloud account.
Sure his gmail account wouldn't have been compromised, but what about his his iCloud and twitter?. Why doesn't apple and twitter provide two-factor authentication? Why doesn't everyone do it this days?
If I'm reading the blog post correctly, his Twitter account was compromised via GMail. If his GMail account had not been compromised, they wouldn't have gained access to his Twitter feed (which was the true target of the attack).
They would still have been able to compromise his iCloud account and thus destroy the data stored on his computers.
Unfortunately, I think that in this particular case, having two-factor auth on GMail wouldn't have helped. His account was compromised by having a password recovery email sent to his iCloud address. Presumably, password recovery bypasses two-factor auth.
In this attack and the earlier CloudFlare attack, the attacker took advantage of inappropriate recovery email settings. While it's reasonable for consumers to enter recovery emails, I think that professionals should avoid enabling them. When a @gmail.com sends recovery mail to @me.com (or vice-versa), the attack surface is greatly increased.
Two-factor Google authentication would have had two benefits. First, the Gmail and Twitter accounts wouldn't have been hacked.
Secondly, the Wired article made this claim: "Because I didn’t have Google’s two-factor authentication turned on, when Phobia entered my Gmail address, he could view the alternate e-mail I had set up for account recovery. Google partially obscures that information, starring out many characters, but there were enough characters available, m••••n@me.com."
I don't know for sure whether that's true or not. But assume it is true. If two-factor authentication had been enabled, then the hackers would have had a much harder time guessing Mat's email address for iCloud and whether he had a @me.com email address at all.
I have two-factor authentication turned on and I can see this much (in a different web browser) without entering anything: "Choose how to get back into your account. Get a password reset link at my recovery email: uch•••••••@c••••.com"
The problem may be that "me.com" is so short that Google might display the full domain name. If that's the case, Google should fix it.
"Hackers would have had a much harder time"? No: mhonan@gmail.com mhonan@me.com
Gmail was not really needed to guess the name at @me.com.
Moreover, in his case, it seems he would be better off not having the secondary e-mail address for recovery at Google. It turned out to be anti-security measure.
It's not the mhonan part the would've been hard to guess but the @me.com. A secondary email account could be anything. It could also very well not be enabled. Knowing that it is enabled and that is an @me was definitely something that helped the attackers.
I disagree. I think most iCloud users (%80 of iOS users by Apple's count) have @me addresses when they upgraded to iOS 5 or Lion. I can use both my @gmail.com and my @me.com in App Store to purchase, or to login to icloud.com.
Good point. But even two-factor auth wouldn't have saved him because the hacker got the customer support people to issue a temporary password. Apple (and others) need to implement better controls on how you reestablish identity once you've lost access.
Wouldn't the hacker still need the temporary password AND the Google Authenticator code? Or are you assuming that the customer support people could and would turn off two-factor auth while resetting the password?
Yes I'm assuming I call a company having lost all access. Would a company have a different way of establishing identity for someone who lost all access if they've implemented TFA?
I've tried turning it on multiple times by using an iPod Touch, but I can't figure it out. The support article says the device is supported but the actual page only asks me for a phone number. Either I'm being obtuse or the steps for non-phone users aren't very clear.
"Myth: I've heard two factor authentication doesn't work in IMAP and POP"
I've found this to be true - to a certain extent. I had two factor authentication turned on and found it to be a nightmare in OSX Mail. Failures to retrieve mail, asking for my password constantly, etc. I was resetting the application passwords every two days. I tried to research a fix, but in the end it became less of a hassle just to turn it off and have my email work 100% of the time.
It's probably a bug in Mail.app in Lion, but I can't say my experiences with two factor auth have been positive.
Definitely a bug in Mail.app, not 2FA. I had no problem with 2-way on IMAP on Lion, Mountain Lion, iOS 5 or iOS 6. But as I use Mail.app constantly I can assure you that it's desperately buggy. At times I had it laying around downloading gigabytes and gigabytes of Gmail mail again and again and again until I took pity and kill it.
I remember having to generate the 2 or 3 times, but it did eventually work for me, on several gmail accounts. That is with both Lion and Mountain Lion.
Matt, your list of objections and counter-objections is great – too good to be hidden away in a Hacker News comment thread and on your blog. It belongs somewhere within the sign-up flow itself:
Comments
For the people that want to turn on two-factor authentication on their Gmail account, here's how to do it: http://support.google.com/accounts/bin/answer.py?hl=en&t... I highly recommend it.
Some of the common misperceptions I see:
Myth: But what if my cell phone doesn't have SMS/signal?
Reality: You can install a standalone program called Google Authenticator, so your cell phone doesn't need a signal.
Myth: Okay, but what about if my cell phone runs out of power (added: or my phone is stolen)?
Reality: You can print out a small piece of paper with 10 one-time rescue codes and put that in your wallet.
Myth: Don't I have to fiddle with an extra PIN every time I log in?
Reality: You can tell Google to trust your computer for 30 days and maybe even longer.
Myth: I heard two-factor authentication doesn't work with POP and IMAP?
Reality: You can still use two-factor authentication even with POP and IMAP. You create a special "application-specific password" that your mail client can use instead of your regular password. You can revoke application-specific passwords at any time.
Myth: Okay, but what if I want to verify how secure Google Authenticator is?
Reality: Google Authenticator is open-source: http://code.google.com/p/google-authenticator/
Hmm. Maybe I should throw this up on my blog too.
I was reluctant to setup two-factor for a long time, perceiving it to be an unnecessary hassle. Then somebody tried to gain access to some of my accounts through my Apple ID. They were unsuccessful (I don't have any common passwords these days so managing to send a password reset to my GMail wasn't terribly helpful) but it certainly made me paranoid enough to switch.
I currently have two-factor setup on two accounts. I won't say there's no hassle involved--authorizing a machine via SMS so that I can login and generate an app-specific password is a chore--but the peace of mind is well worth the hassle.
Did you also know that you can re-assign your Apple ID to an existing e-mail address? Like, say, one you have two-factor enabled for? Now people can socially engineer Apple's flawed policy all day but they'll need to steal my phone, too.
EDIT: Also, if you don't have backups, you might as well just delete everything yourself right now and use that as motivation to prevent the same thing from happening again. Hackers, tornadoes, spontaneous combustion and ghosts are all conspiring to destroy your data sooner or later.
Have you encountered any other sites that allow you to use Google Authenticator to generate OTPs?
Part of the reason I think two-factor authentication is a usability burden is because each "identity provider" wants to use its own protocol. Google uses an Android app. PayPal sent me a card. My brokerage has a keychain token available. Other companies use a "soft" RSA token that runs on Windows. But if everyone agreed on a protocol, then I could have everything in one place, which would make two factor authentication significantly more enjoyable to use. (I know there are standards: the question is, who other than Google follows them? :)
Good question. I have seen http://drupal.org/project/ga_login for Drupal, for example. Likewise, here's a write-up about using a YubiKey with Gmail's two-factor authentication: http://static.yubico.com/var/uploads/pdfs/Howto_GmailYubiKey...
I believe Google Authenticator is based on open standards and open source, so people could standardize on it if they wanted too.
> I believe Google Authenticator is based on open standards
The standards implemented are bonafide RFCs - HOTP (counter-based) was published in 2005, no less. I'm not sure how much lower the barriers for integration could be.
Lastpass also uses Google Authenticator. You can get server-side code so you can use Google Authenticator on your own server, or use it to offer two-factor authentication to a web service you are running. It's an open protocol, with an open source implementation. All you have to use it.
Amazon AWS supports the google authenticator app.
It is an open standard protocol, but I don't know in practice how many companies have compatible implementations.
A lot of the tokens(Google Auth included) follow http://www.ietf.org/rfc/rfc4226.txt. Problem is everyone has a different way of provisioning the secure key. Some of which are unsafe (I am looking at you Google Authenticator!. Yes a qrcode is kool idea but theres no guarantee that you are the only one who provisions the key using the image.)
I designed Authy with that in mind. I wanted a way to have a 1 token for all accounts. Maybe we will add support for Google Authenticator, so you could import your Google Auth token into the app.
I use pam_google_authenticator to login (via SSH) to my Linux server, and so can you.
Meraki (full disclosure: my employer) has two-factor authentication for their network config/admin web interface; whatever the tool used (I haven't worked on that part of our codebase), it is compatible with Google Authenticator.
There's a Google Authenticator WordPress plugin: http://wordpress.org/extend/plugins/google-authenticator/
DreamHost use Google Authenticator.
The bitcoin exchange MtGox supports securing your account with the Google Authenticator app.
Lastpass for one supports Google Authenticator. I am not sure about any other services.
Facebook. See https://www.facebook.com/settings?tab=security§ion=a...
As far as I can tell, this offers no way to use Google Authenticator. Only the Facebook for Android app.
FB doesn't use Google Authenticator.
Not quite the same as two factor auth (almost the opposite in fact), but I was extremely annoyed when gmail started relentlessly asking me to add a backup email address for password resets. Had the author not had an insecure backup email address, this wouldn't have happened either. Of all the passwords I'm likely to forget, gmail ranks near the bottom. The password to login to who knows where to get the gmail recovery email? The top.
That's absolutely true. I was horrified last week when I discovered my Gmail account (with a unique 30-character long password, 2-factor enabled, NEVER used unless on my MacBook at my house) had a "backup" email address to my Yahoo account from 8 years ago, with the nice password '1123581321'. I could've killed myself.
That's amazing. I've got the same combination on my luggage.
Why do you use the term 'application-specific passwords' although these passwords are not application-specific at all?
They are Google-generated passwords with a user label. And if you use 2-factor authentication, they are the weakest link in the chain since they provide full access to a google account except for access vectors with 2-factor authentication. In addition, every app can use such a password, not just the app you created the password for …
2-factor authentication is great and certainly recommendable but you should not fool users by using the false term 'application-specific passwords'. In addition, more complex Google-generated password would be appreciated.
Application-specific is just a friendly name.
Also this password doesn't give you full access to your Google account. You cannot log into Google web apps this way (AFAIR). Thus you won't be able to mess with account settings (passwords etc). Before you can change critical account settings Google asks you to provide your traditional password again.
Your comment is a bit harsh if not FUD.
'Application-specific' is IMHO not just a friendly but a misleading name. They are simply not application-specific.
Using one of these so-called application-specific passwords, you can delete calendars, mails and contacts. That is critical enough for most users.
An additional concern is the usual 30-day authorization you give in order to avoid entering your 2-factor token again and again. Is there any way to de-authorize such a 30-day authorization?
Anyway, I don't rule out that my perspective might be too strict. For must users, the whole Google 2-step authentication system is probably a very important step towards improved security.
There's something that bugged me about two-factor the moment I activated it. The application specific passwords are stored in plain-text. How does Google know that it's actually e.g. Chrome accessing my mail with a given application-specific password?
If a hacker gets a hold of an old backup of mine, which includes a Pidgin configuration file I forgot to delete, which holds a plaintext password, can he get into my account with that?
If you didn't revoke the application-specific password. And you should be revoking them when you're no longer using them.
If you weren't using application specific passwords, of course, it would have been your actual Google password in that Pidgin config.
It's a little disappointing that the app-specific password isn't more secure, but it's certainly not less secure than foregoing them.
App-specific passwords are bypasses of 2-factor auth. Use them selectively and with care, revoke ones you're not using anymore. And replace them from time to time.
Two-factor authentication is as secure as you make it.
If you value security more than convenience don't use application specific passwords. Google certainly allows for that by only consuming their services through a secure web interface. Is there another mainstream e-mail provider who supports that?
However, if you would like to use apps, gtalk, pidgin, etc. Google will still let you and it will still be more secure than before (revoke specific passwords, etc.).
If one of your application specific passwords (ASPs) is compromised your e-mail content will be compromised but NOT your account as long as your phone / token generator are under your control, allowing you to recover access by your own means. That is a big difference.
That's exactly why I don't use 2-factor. It's only as secure as a single complex token. I use a password manager with complex passwords. I fail to see the added security of enabling 2-factor in this case.
Since I've been downvoted without a response, let me elaborate on my concerns. I haven't seen the threat of application specific passwords (ASP) addressed properly. If an ASP is sniffed or somehow extracted from a device it seems like it's practically equivalent to a single-factor authentication password. I couldn't determine from Google's docs if an ASP will allow you to change a master password or not. Or if it could be used in the place of a master password. It seems like it can only be used through apps that utilize Google APIs. Does anyone know if one of those APIs allows for changing of the master password?
A quick search shows that others share my concern about ASPs: http://webapps.stackexchange.com/questions/13317/how-does-ap... http://tech.kateva.org/2011/07/massive-security-hole-in-goog... https://groups.google.com/forum/#!topic/chromebook-central/z...
When you need to make any changes to the 2-factor settings, you must enter your account password and the 2-factor password. The ASP cannot be used for this purpose.
I'm kind of wary of the ASP. It feels very backdoorish. And by the very nature of ASP, it is meant to be saved/stored on the computer system.
Me too. It seems to me that since ASP allows me POP/IMAP access to a gmail account, it probably gives me enough access to run the "send a password reset" attack. I can't use that to 0wn the two-factor protected google account, but I can easily use it to 0wn the AppleID/Anazon/eBay/PayPal account using the gmail account for the recovery address…
Off the top of my head, I don't even know if it's possible to ensure my iPhone or GalaxySII is using SSL/TLS for it's POP/IMAP connections (or if an attacker with brief access to my device could switch it to plain-text-passwords then sniff it's authentication on the local wifi).
Gmail supports restricting POP/IMAP access to specific labels. Couldn't you set up filters to move password reset emails/all emails from services you care about out to non-POP/IMAP folders, skipping the inbox.
A kludge, sure, but a possibility.
Then we should probably move towards (something like) OAuth in all our apps, be it web, desktop or mobile. This way a potential evildoer is left only with a very limited token. Even more, we can invalidate tokens based on time and device used.
Having OAuth or Two factor in Google Talk/Chrome or any application based login system shouldn't be THAT hard. Along with your password, there should be another text field stating "OTP" or some other friendly name.
2FA is equivalent to changing your password every 30 seconds. Yes, it's "only" as secure as that single token, but the entire point of doing 2FA on a separate hardware device is that even if you have every piece of malware installed on the machine you're logging in to, there is still an analog transfer of information from your phone(/keyfob/whatever) to your computer via your brain. It keeps your "password" in two parts, one of which lives in your head/password manager/muscle memory, and the other of which lives on your phone.
ASPs are certainly less secure than 2FA, but they only permit services access, rather than account administration access.
2FA is slightly more hassle for the knowledge that you are effectively protected against a wide range of attacks. It's very worth it.
That reminds me of discussion on desktop security where often root access is seen as they holy grail – while the potential for damage with simple user access gets ignored …
2-step authentication is great but the (wrongly) so-called application-specific passwords are definitely the weakest link in the chain. They do not allow for a full takeover of a Google Apps account but there is still a lot of damage possible.
The two big players here (Vasco and RSA) both do this in hardware and software. So there are soft devices that run on desktops, mobile, etc.
Two factor limits the time window within which a password is useful. If one of your complex password's hashes gets exposed, someone would need to also know your ssl-only two factor auth cookie, and then reverse/bruteforce your password within the 30 day window the cookie makes it valid for - that makes the "current model" of releasing the hashes on pastebin and crowdsourcing the hash-cracking much more time critical.
Are you asking if a hacker could use the application-specific password to access your email account? I'm pretty sure the application-specific passwords are only good for the service using them (e.g. the first service to use a newly generated password is the only one allowed to ever use it), but that would be trivial to test for yourself.
That can't work - how would they identify the service using them? Ip address is useless for this purpose and other identifiers ar either not available or very easily spoofed and thus equally useless. If somebody gets hold of the application specific password, he'llbe able to use said application.
You're right, I'm not sure how I thought that could work.
I just used the same password to login to my Talk account in Pidgin and later for my Android. This is really insecure, especially when Pidgin saves passwords in plain text.
You're perfectly welcome to use the same password multiple times-- it's as secure as you yourself make it. When Google generates an App password, it displays it once-- and then trashes it. On that same page is a list of the identifiers you've given all of your apps, and the last time that identifier's password was used to log into your account. At any point, you can trash a generated password, and anything using that password can't log into your account anymore.
If you use the same generated password for every application, then you're not in that much better a situation than you would be otherwise. If you use different identifiers for each application, you can identify exactly where a breach happened from by last login time, and disable that password entirely.
Kind of. This is the reason 2-factor makes me uncomfortable too: instead of having 1 username/1 password, it's actually 1 username/lots of passwords. And the passwords generated are all lowercase alphabetic characters (I assume to make them easier for users who don't/can't copy-paste).
It'd make me a lot more comfortable if I could lock each password down to a specific Google service (for instance: generate an OTP for Pidgin, and enable it only for Google Talk), they were a lot longer, and had special chars + numbers in them.
ASPs are 16 characters. That's 26^16 - 26^15 = 4.19315 * 10^22 (41.9 sextillion!) cominbations. If you aren't confident in the size of that keyspace, I'm not sure what to tell you.
The point about permitting a password to be used for only certain services is absolutely a valid one, though.
You are right and that's what I'm going to do. But it's no less secure until you don't "remember" that token anywhere. A remembered password in Google Talk (desktop client) is just encrypted and can be easily recovered.
Edit: To add to my reply, I have never used the remember password for Pidgin in the past, however enabling 2 step auth require me to do that. It'd be great if Google could somehow allow only the first associated app with a password for subsequent uses. Technically that looks very challenging (if at all possible).
Sounds as if Pidgin is the problem here.
I know that at first look it sounds like a Pidgin problem, but they do justify their situation quite well on their site: http://developer.pidgin.im/wiki/PlainTextPasswords
this is crazy, doesn't every current linux distro already have a keychain-like-thingy which is protected by the user password? Adium (which is also based on libpurple) uses it on the mac, which means there is no plaintext password lying around.
There is - GNOME has Keyring, KDE has Wallet. But apps need to support it or have a plugin system for that. Pidgin has plugins for GNOME and Windows: http://developer.pidgin.im/wiki/ThirdPartyPlugins#Securityan...
They have a point - if Google really allows other apps to access the account via Pidgin's password, perhaps they should fix that.
That is not possible with the current 2-factor authentication system. App-specific passwords are only called 'specific', they are not really app-specific, i.e. you can use them with any app you like if 2-factor authentication with a token has not been implemented yet.
If Pidgin is your use-case, the only solution is not using Pidgin.
http://code.google.com/p/google-authenticator/issues/detail?...
The inflexible account ordering in Authenticator is bugging me, since I recently added a 5th account (not 5 google accounts) and my phone only shows 4 at a time. I don't know if you have any influence over the people maintaining the app, but it looks trivial to fix, given the comments.
That's good feedback--I'll pass it on.
I was wary to set up 2FA until I learned that you can set it up even without a cellphone or your own computer. You can have the second factor be a voice call, so it can call a landline or dumbphone without an SMS plan. Plus, if you ever lose your phone or cancel your number, you can set up backup phone numbers. I set up my fiancee's phone number as a backup number in case I ever lose my phone.
Someone big got hacked this way recently - the attacker managed to social-engineer a call forwarding change, then used a "landline 2FA auth call" to gain the foothold then needed. (I think it was Cloudflare?)
It's similar to @mat's problem - Amazon assumed the CC last 4 digits was "non identifying", Apple assumed they were.
How much effort do you suppose your phone company expends securing your voicemail or call forwarding? I'll bet it's less than would be considered "industry best practice" for securing your corporate dns records…
I heard about this hack too (http://blog.cloudflare.com/the-four-critical-security-flaws-...), but I disagree with you - the last 4 CC digits should be considered non-identifying.
First, let me explain a little bit of background on this "hack". From the article, they had 4 problems with their process that allowed them to get hacked badly:
1. AT&T was tricked into redirecting my voicemail to a fraudulent voicemail box;
2. Google's account recovery process was tricked by the fraudulent voicemail box and left an account recovery PIN code that allowed my personal Gmail account to be reset;
3. A flaw in Google's Enterprise Apps account recovery process allowed the hacker to bypass two-factor authentication on my CloudFlare.com address; and
4. CloudFlare BCCing transactional emails to some administrative accounts allowed the hacker to reset the password of a customer once the hacker had gained access to the administrative email account.
I'm not really sure what #3 is and #4 is irrelevant to our discussion, so I'll concentrate on points #1 and #2.
From #1, it follows that the attackers were able to obtain the phone number associated with the two factor auth. How did this work? My assumption is that it was a very targeted attack.
The article starts the attack at June 1st, 2012, but I believe (read: assume) that the attackers probably met the target of the attack beforehand and obtained his/her business card (with a cellphone number), which allowed them to perform #1 above.
So, given that this attack required a physical piece of paper (i.e. a business card) to be acquired from the target, it is not a stretch of imagination to say that if another attacker wanted to obtain the last 4 digits of someone's credit card, all they need to do is follow the person to a restaurant or gas station and get a payment receipt -- every receipt has the last 4 digits written on it. Some have the first four.
Therefore, I don't believe it was Amazon's fault for assuming the last 4 digits are non-identifying, but rather Apple's fault for assuming they are. To be clear, hindsight is 20/20, so I think it was relatively reasonable for Apple to assume that. However, I do expect Apple to change this policy in the future.
I think we're vigorously in agreement here - the last 4 CC digits are certainly not identifying, and I'm perhaps a little less forgiving that you in letting Apple off for thinking so. I'm also not happy with Amazon's assumption that they should be displaying them quite so easily (although at least they don't display them until you're far enough "in" to an account - and it's not easy to work out an alternative way to distinguish between several different CC's when you can have more than one linked to your account).
(And, there are many alternative and easier ways to acquire most people's cellphone number - no need to meet someone or get them to give you a business card… But your point still stands…)
My apologies, I somehow glossed over the Apple part of your post. I agree with everything you said, perhaps even about being forgiving of Apple using the last 4 digits as a verification mechanism.
It's true about a cellphone number -- from what I heard about his attack outside of this article, this a very targeted attack, and the attacker knew exactly what kind of data to expect in the GMail account, which is what led me to conclude that the attacker probably knew or met the victim, but likewise, good point about obtaining the cell in other ways.
See above for Matt Cutt's answer: you can also use a yubikey (a tiny USB device that pretends to be a keyboard, and enters the code when you press a tiny button on top).
How well does this work if you are in, say, South-east Asia?
I have been using it in Vietnam for over a year without any major problems and I have suggested a few family members (who are not tech savvy at all) to use it too.
The app works very good on both Android and iOS (I personally use the iOS app because I flashed new ROM all the time and sometimes Titanium Backup of the app doesn't work). I tried the SMS a few times, the message normally arrives within one minute.
I am in Singapore and have been using it for a couple of months now. Works great.
There seems to be something funky with "application-specific passwords" (ASP) on Chrome. Let me explain the problem (that I documented to a friend ~1 month ago): I just revoked all Google Chrome keys, cleared out all of my history / cookies / passwords / forms, etc.
I went to a different computer that had previously had Chrome synced using ASP, switched to my account, and went to settings. At the top, I get this error message: "Account sign-in details are out of date. Sign in again" That's good since ASP was revoked. But then I go down to advanced settings => passwords, and they're all still visible?!?! That's just WRONG! If the ASP login credentials have been revoked, access to all locally stored passwords need to be revoked too!
Any idea what's going on? This seems like a flaw. The 2-factor authentication is still great though.
Did you also file it with Google? Definitely a nasty bug in implementation.
The friend was a GOOG employee, but not a member of the Chrome team. Indeed, I should file an official bug report... but the Matt Cutts bug reporting system is usually so much more responsive. ;-)
Myth: Right, but what happens in the very common scenario of my Android phone-- logged into Google with the Authenticator installed-- getting lost / stolen? Surely then 2-factor auth is basically useless?
(insert your answer below)
Reality: You go into Google account security and choose 'Clear the phone info and printable codes' and 'Forget all other trusted computers. Require a verification code the next time I log in from any other computer'.
I think the answer is that you can print out one-time codes on paper and put them into your wallet.
I would also recommend putting an unlock pattern on your phone to protect in case your phone is stolen.
I just set up 2-factor auth
1) You still need to enter your password every time you log in.
2) You can add backup phones that can be called/texted with the verification codes
3) You can print out back-up codes that will always work (once)
4) If your phone is stolen and is using an application-specific password, you can revoke that password for that application.
What are you trying to protect against in this case?
If your phone gets stolen and it's logged in to your google mail without a lockscreen pin/code, then yeah - the thief can read your mail, 2fa won't help. They can also run your Authenticator app and see the current 6 digit number, but that's not useful without the password as well.
(I'm not sure how easy it is to extract the Google password from an Android or i phone - I wonder if you can just switch them to non-TLS POP3 or IMAP and have them send a cleartext password over an unencrypted wifi connection?)
If the phone is rooted(as is the case with mine) then an attacker could change the list of trusted Certificate Authorities on the phone and then perform a MITM attack to get any passwords being passed over the air.
However, I think google services use XMPP if I'm not mistaken. In which case the password is never actually transmitted over the air. XMPP uses Digest access authentication[1]. Short version: the server would first send a challenge to the client. The client hashes the challenge with a hash of the password and returns the result. The server performs the same operation and compares. So even with a MITM you'd get nothing. Furthermore, the client itself would never need to store the password either.
[1] http://en.wikipedia.org/wiki/Digest_access_authentication
If you have two-factor auth enabled, your Android phone stores a app-specific password -- even if extracted, it wouldn't be terribly useful (assuming you revoke it).
You should be using POP or IMAP only on your phone so that you can revoke permission after it is stolen (when you log in to your account from a desktop and use a backup key from the printout). If you are logged in to your main Google account on your phone you are asking for trouble. While I will be sympathetic after it gets stolen and someone ruins your life, I won't be surprised.
If you're logged into your Google account from your Android, it's roughly the same amount of control as an IMAP account would give.
They can wreck havoc, but they cannot change your password and steal your account.
What if i lost my phone and didn't print backup codes? Will i lose my google account forever?
There are other backup measures, including a trusted friend's phone as backup. But being totally locked out is a feature, not a bug.
Yes. The aim is that someone without authentication can't get into your account.
If you regain control of the phone number before someone finds the phone and uses it to seize control of the Google account, you wouldn't lose anything more than the phone.
Sounds like a lot of effort, or at least a lot of things to consider. I wonder how many people were completely locked out of their accounts because they enabled 2-factor auth and didn't do all the right things.
The root problem in this story is that things are just too damn interconnected these days. And we're encourage to interconnect them even further (using cellphones to authenticate email, in this case).
Edit: I think that my reply is not harsh enough. After reading the comments more closely, I see that this a typical IT response to IT failure. 1. Ignore the root cause. (Interconnectedness.) 2. Blame the user. (Implicitly, for not enabling two-factor auth.) 3. Suggest a workaround and dismiss any concerns real-life scenarios. (E.g. loosing your wallet and cellphone in an emergency. Emergencies like that happen more often that you'd think.) 4. Feel smug.
Although enabling two-factor auth in gmail is great, I still fail to see how it would have protected his iCloud account. Sure his gmail account wouldn't have been compromised, but what about his his iCloud and twitter?. Why doesn't apple and twitter provide two-factor authentication? Why doesn't everyone do it this days?
If I'm reading the blog post correctly, his Twitter account was compromised via GMail. If his GMail account had not been compromised, they wouldn't have gained access to his Twitter feed (which was the true target of the attack).
They would still have been able to compromise his iCloud account and thus destroy the data stored on his computers.
Unfortunately, I think that in this particular case, having two-factor auth on GMail wouldn't have helped. His account was compromised by having a password recovery email sent to his iCloud address. Presumably, password recovery bypasses two-factor auth.
In this attack and the earlier CloudFlare attack, the attacker took advantage of inappropriate recovery email settings. While it's reasonable for consumers to enter recovery emails, I think that professionals should avoid enabling them. When a @gmail.com sends recovery mail to @me.com (or vice-versa), the attack surface is greatly increased.
Password recovery does not bypass two-factor auth.
Two-factor Google authentication would have had two benefits. First, the Gmail and Twitter accounts wouldn't have been hacked.
Secondly, the Wired article made this claim: "Because I didn’t have Google’s two-factor authentication turned on, when Phobia entered my Gmail address, he could view the alternate e-mail I had set up for account recovery. Google partially obscures that information, starring out many characters, but there were enough characters available, m••••n@me.com."
I don't know for sure whether that's true or not. But assume it is true. If two-factor authentication had been enabled, then the hackers would have had a much harder time guessing Mat's email address for iCloud and whether he had a @me.com email address at all.
I have two-factor authentication turned on and I can see this much (in a different web browser) without entering anything: "Choose how to get back into your account. Get a password reset link at my recovery email: uch•••••••@c••••.com"
The problem may be that "me.com" is so short that Google might display the full domain name. If that's the case, Google should fix it.
"Hackers would have had a much harder time"? No: mhonan@gmail.com mhonan@me.com
Gmail was not really needed to guess the name at @me.com.
Moreover, in his case, it seems he would be better off not having the secondary e-mail address for recovery at Google. It turned out to be anti-security measure.
It's not the mhonan part the would've been hard to guess but the @me.com. A secondary email account could be anything. It could also very well not be enabled. Knowing that it is enabled and that is an @me was definitely something that helped the attackers.
> ..whether he had a @me.com email address at all
I disagree. I think most iCloud users (%80 of iOS users by Apple's count) have @me addresses when they upgraded to iOS 5 or Lion. I can use both my @gmail.com and my @me.com in App Store to purchase, or to login to icloud.com.
Good point. But even two-factor auth wouldn't have saved him because the hacker got the customer support people to issue a temporary password. Apple (and others) need to implement better controls on how you reestablish identity once you've lost access.
Wouldn't the hacker still need the temporary password AND the Google Authenticator code? Or are you assuming that the customer support people could and would turn off two-factor auth while resetting the password?
Yes I'm assuming I call a company having lost all access. Would a company have a different way of establishing identity for someone who lost all access if they've implemented TFA?
Que the "Apple locked me out of my OWN DATA!" screed in 3, 2, ...
I discussed the answer to your first question here: http://news.ycombinator.com/item?id=4348537
I've tried turning it on multiple times by using an iPod Touch, but I can't figure it out. The support article says the device is supported but the actual page only asks me for a phone number. Either I'm being obtuse or the steps for non-phone users aren't very clear.
There's no Google Authenticator for Windows Phone, but there's an equivalent: http://www.windowsphone.com/en-US/apps/021dd79f-0598-e011-98...
"Myth: I've heard two factor authentication doesn't work in IMAP and POP"
I've found this to be true - to a certain extent. I had two factor authentication turned on and found it to be a nightmare in OSX Mail. Failures to retrieve mail, asking for my password constantly, etc. I was resetting the application passwords every two days. I tried to research a fix, but in the end it became less of a hassle just to turn it off and have my email work 100% of the time.
It's probably a bug in Mail.app in Lion, but I can't say my experiences with two factor auth have been positive.
Definitely a bug in Mail.app, not 2FA. I had no problem with 2-way on IMAP on Lion, Mountain Lion, iOS 5 or iOS 6. But as I use Mail.app constantly I can assure you that it's desperately buggy. At times I had it laying around downloading gigabytes and gigabytes of Gmail mail again and again and again until I took pity and kill it.
Make sure you're using an application-specific password for any application that doesn't support two factor authentication - eg, Mail.app on Lion.
Thats what they're for.
I remember having to generate the 2 or 3 times, but it did eventually work for me, on several gmail accounts. That is with both Lion and Mountain Lion.
Matt, your list of objections and counter-objections is great – too good to be hidden away in a Hacker News comment thread and on your blog. It belongs somewhere within the sign-up flow itself:
http://support.google.com/accounts/bin/topic.py?hl=en&to...
Well that answered all my misgivings about 2 factor with Gmail. I'm setting it up now. Thanks!
convinced - i will set it up in a minute :)