Hacker News Reader

Comment by wting | Hacker News Reader

Multi-factor authentication means choosing from:

1. something you know (password)

2. something you have (phone, yubikey)

3. something you are (biometrics)

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.

View on HN

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?

All I can figure is it makes it easier to revoke one password without changing all the others.

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.

Accessing your email box is a different matter than taking over the whole account. The former you can generally recover from.

That's the problem though, isn't it? They don't do password specific permissions, so any leak escalates up to taking over the whole account.

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.

Not true. Read the article :)

The article says it's fixed.

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...

The Google "Application Specific Passwords" are actually complete passwords which give you access to all data in the account, which is the problem.

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.

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…)

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.

Reply on news.ycombinator.com