Could anyone explain to me what's the point of Google's two-factor authentication? I mean, before that, I used to have one password I had to guard carefully, and now I have ten passwords I have to guard carefully, and the one I enter most often requires me to additionally type some digits I have to read from my smartphone? What plausible attack scenario does two-factor authentication protect me from?
With Google's two-factor, logging in requires something you know (password) and something you have (phone). The 10 passwords should be locked somewhere physically safe as a fail-safe.
Two-factor authentication protects against password leaks and brute force password attacks.[0] It now takes two security failures to access your account rather than one.
On a side note, this is why secret questions are worthless as a security measure. Backing up a password with another mental fact is still single factor authentication.
[0]: Unless the attackers were able to attain your fail-safe passwords, but unlikely given the entropy and presumably Google's security.
I'm not talking about 10 passwords I have as a backup. I'm talking about 10 application specific password that are used every day by my phone, mail client, xmpp client etc. They just need to intercept any single of these password to compromise my mail account. How's this different from the situation before two-factor authentication?
You are confused by the misleading "application-specific password" terminology. These passwords each allow the same degree of access: the password you use on your phone could be interchanged with the one on your xmpp client. Aside from being able to revoke each independently, there's not much benefit from having many of them.
These are not equivalent to 2-factor auth (which grants you the benefits described in an earlier comment). App-specific passwords exist only to allow you, a 2-factor user, to use applications which do not yet support 2-factor auth.
The primary purpose is to reduce the impact of password reuse or the user interactively disclosing their password to an attacker. Primarily leaked password hashes and phishing attacks, but it also combats sslstrip style mitm attacks and keyloggers on public computers. Nobody is going around typing in ASPs.
It's not designed to mitigate your personal computer being compromised - the only solutions that can move the needle in that situation are far beyond anything normal folks are willing to put up with.
I think this is the answer, and I think it would have made sense if they'd called it a "device specific password" instead of an "application specific password".
I've got an asp (dsp?) for my phone (which all the applications that need one on my phone use), another for my iPad, another for each of my laptops, home computers, and my work computer. If I lose (or have stolen) my phone, I can revoke the password it knows - without needing to change any of my other devices.
Using the word "Application" allows everybody (including, I think, google's own security people) to make the incorrect assumption that the "iPhone mail password" is "specific" to mail - and only allows POP and IMAP to work. Instead, what "application" means is not the easily assumed "a piece of software" interpretation, but the "use to which something is put" interpretation. The decision and management of that "use to which a password is put" is not made nor emforced by Google, but is all up to _me_ (or, as it turned out, to any attacker who could lever one out of me).
Right. AFAICT, there's nothing inherently "specific" about the password at all, that name is mostly just a "serving suggesion" to the legitimate user (one which the attacker is free to ignore).
So calling it a "device specific password" doesn't make it any more sensible to me. I'd call it an "alternate weakest-link redundant password" to be precise, but Marketing rarely goes with my suggestions. :-)
Google does intentionally make it a little more difficult to do what you are doing by refusing to ever show you the password again once it has been generated. You have to store that "unmemorizable" sixteen letter password somewhere.
The workflow they seem to encourage is that an "application" asks for your password, you open a browser and generate a new ASP, then save it in that app and forget it forever.
By "application" they mean "something that asks for your password." Thunderbird or iChat, not IMAP or XMPP.
Your right, a password that only works for a specific service or property or protocol would help, but "email box" is not the best example of your point - even if the only Google access is could steal off you was the ability to read you mail, you've pretty much hosed - I can now go to every other website and ask them to send you a password reset, and you're now lost down the Mat Honan rabbit hole. Where does your appleID reset go? Or your domain registrar accounts? Your Facebook/Twitter/HN password reset email?
> I can now go to every other website and ask them to send you a password reset
Yes, and, provided I've discovered the issue in time, I can use one of my ten reset codes or OTP to log in, revoke/disable all my ASPs, and reset them again. Recoverable.
If you'd stolen my whole Google account, you've likely regenerated the codes and changed the backup email and phone number. No exit.
Sure, but that "provided I've discovered the issue in time" leaves a gaping hole for a sneaky attacker. If I've got your email password, and I'm camped on your email account while hitting all the other website's forgot password forms, and I delete all the mail as soon as I've retrieved the link - how do you "discover the issue"? In some ways, that sort of attack is even more insidious than taking over the Google account completely - at least being locked out of your account raises the big red flags immediately, how would you even notice I was reading all your mail with a stolen ASP? (While I'm being particularly evil in my thinking, I'm imagining an attacker quietly gaining access to read email, and not actively doing anything to arouse suspicion, then waiting for _you_ to hit passwrod reset links on various high-value-to-the-attacker sites, perhaps forcing that on you by triggering brute force protection on those other sites…)
They don't let you log in via the web, only via protocols that have a single field for "password", like xmpp, imap, and smtp. There is tons of data in the account which is not accessible with an ASP.
When you try to log in on the web with an ASP, it asks for the account password + OTP.
That's (probably) true right now, but the article points out that mis-using the chrome autologin mechanism allowed access to anything - including unfettered access to your account settings page - with just an ASP. This was true for at least 7 months. Until last Thursday, your xmpp ASP did give anyone with some specific knowledge access to all of what you think of as "data in the account which is not accessible with an ASP".
_Hopefully_ the fix in place now makes your statement correct now and in the future. But this shit is hard - I wouldn't be betting my house on it not having further flaws.
Constructive suggestion: create a new, non-obvious, high reliability email account. Don't use it for anything except as a password recovery email address for high importance accounts. I have my Google/Apple/Amazon/eBay/PayPal/DomainRegistrars/webhosting accounts pointed to it, but not things like Twitter/FaceBook/LinkedIn/forums/HN/n-random-website. Document carefully where you've used it so in the case of a high-profile intrusion on one of your "high importance" websites you know exactly where you need to change that email address (to prevent an attacker being able to leverage the disclosure of that email address). Don't ever publish that address anywhere else. I know this is mostly "security through obscurity", which is in crypto contexts a totally flawed proposition, but in terms of "reducing the attack surface" of your critical online accounts, I think it's an effective tactic.
No, ASPs can only be used to access account data available over imap, smtp, xmpp, and other non-web protocols that don't allow cookies/asking for the OTP.
The fix that Google rolled out blocks ASP-based logins from accessing a few highly-sensitive pages on https://accounts.google.com, but otherwise, little has changed. With a quick API request, you can still use an ASP to skip just about any other Google web-based login anywhere on the web. Google might have to completely eliminate their Chrome/Android auto-login feature to actually prevent this sort of thing...
You don't have to steal a master password. It's enough to steal an application specific password, and if you do that, you won't need a smartphone to read my mail.
The main advantage is that people need to remember lower entropy passwords or can use the same password in multiple places without compromising two factor protected system. Also two factor auth protects against keyloggers.
Because the code is sent to a device Google know you have had physical possession of in the past. It's either sent by SMS, voice call, or to a pre-registered mobile app.
The general point of two factor authentication is that you need physical access to something (phone, token generator, etc), meaning that if somebody across the world knew your password they'd still be unable to cause any damage - or rather, it would take a lot more effort.
> Because the code is sent to a device Google know you have had physical possession of in the past. It's either sent by SMS, voice call, or to a pre-registered mobile app.
None of those connect to device you've had "physical possession in the past". Only the present. Phone calls, SMS and apps are all portable across hardware.
For TOTP, you can have the same account on more than one device (I do for convenience). All you need is the initial seed which you can either enter manually, or scan the barcode using more than one device.
If they know my master password, they also need to have a phone, that is correct. But if they know a single application specific password, they can read my mail just fine. How does the two-factor authentication protect me in this case?
Could anyone explain to me what's the point of Google's two-factor authentication?
Without application specific passwords it's actually pretty secure. With ASP of course, according to this article, it's no more secure at all. So it looks like ASPs need to be revised/locked down. That doesn't mean that 2-factor security is useless in principle, just that this facet of it is insecure.
The really funny situation regarding the phone is that Google makes you do this when logging in on your phone too. So if you go buy a new phone, in order to log in you will have to undergo a few failed attempts, use their web log in form, which SMSs a password to the very same device you're using in the first place.
