This is great - getting access to your mail account allows someone to essentially take over your online identity, so this helps a lot.

I do hope that you can't get in just by knowing someone's mother's maiden name, though...

RTFA, Google sends a code to your phone.

Actually, I was talking about the backup method. Happily, that's a list of printable one-time codes. (Obviously, locking you out of your GMail if you lose your phone is not acceptable.)

Devil's advocate here:

If I can trick a user into submitting their username and password on my site, I can send a request to Google using that username/password and trigger a message to the mobile application. The user continues with the flow, enters the code on my screen, and I now have access to their account, same as before.

Yes. 2-factor authentication does not address site impersonation.

This is for the more common case of trying to access a user's account without the user's direct involvement. (e.g., if I grabbed lists of common passwords, try to use your password from a cracked site to access an account on google, etc.).

Classify this as "step forward" not "silver bullet".

kb

Except they specifically list anti-phishing as one of the use-cases:

"if you reuse the same password on multiple sites and one of those sites gets hacked, or your password is conned out of you directly through a phishing scam, it can be used to access some of your most closely-held information."

You're right that it helps in cases where all the attacker has is your username and password. However, the blog post overstates the merits of this feature a little bit. ;)

I don't think 2-factor auth as proposed by Google is designed to prevent man-in-the-middle attacks: http://www.phonefactor.com/man-in-the-middle-attacks

In order to prevent MITM, Google would need to have out-of-band verification (not just two tokens processed on the same band).

The benefit of Google's method is that a password can't be cached for later use, which reduces the window in which an account can be compromised.

How is this any different than the prior situation?

Now instead of needing to trick a user into giving you their username and password, you need to trick them into giving you their username, password, and one-time token.

It's designed to address situations where the password is discovered by other parties.

The attacker would have access only for that session.

You have access until the session times out, then you'll need to make the attack again.

Granted, you can do a lot of damage before the timeout, but it's not quite as "game over" as if you got the password of a one-key system.

But there is no way to get a valid certificate for gmail.com, and people will notice!

Yeah, </sarcasm>. But it's still a big improvement.

Seems to be the same thing with the BlizzAuthenticator. Good idea, but I wouldn't use it. You gotta consider what happens if you loose your phone. You can't do any emergency calls and don't even have access to your saved phone numbers anymore. You're also locked out of your Gmail Account for god knows how long. I like my phone, but a little bit decentralizing can never be wrong :)

You can print out a set of one-time codes and then put that paper in your wallet. That's what I'm doing.

I have a relative with a fire proof gun safe in another state. This is a good place for crypto keys, master passwords, etc. For the cost of overnight Fed Ex, I can recover from a disaster.

I've been using this two factor for a while via google apps for business and there are multiple failover options:

1 - hard copy code printout (optional) 2 - failover to secondary phone (optional)

This is great - and it begs the question why my brokerage and banking accounts don't offer something similar, especially considering I have iPhone apps from both that could be providing the second authentication factor.

BofA uses something similar when transferring funds between accounts--a unique code is texted to a registered mobile device to complete the transfer. It seems feasible that they could extend the technology to logins.

Four or five years ago I did some work with a company that provides online banking web platforms to smaller regional banks. I asked the CEO about 1+1 authentication (at the time in the context of a RSAID type keychain fob device) and he said they'd pitched it but there was no interest from the banks. In their defense, maybe those RSA thingies are just too expensive for consumer accounts, I do know Citi now provides them to business accounts.

OTP's are much more popular with European banks. Companies such as Vasco sell lot's of OTP fobs there. It's gaining traction here in the US as well though.

A competitor for RSA's SecurID:

http://en.wikipedia.org/wiki/SecurID

I've been thinking how you'd do this as a generic application for web apps. A daemon somewhere on the web that resets your password once a day for all the web apps you use to "original password+unique daily code". Then you log in with that code from your phone and your original password.

My friend Dug Song is tackling this problem:

http://www.duosecurity.com

Very interesting, I assumed someone would be working on something like this. I guess it's a big market, if you can convince bigcos to trust the phone to be secure.

But then you need to have the original password in cleartext somewhere, so I would say that is not the way you do it. I think the way this is more likely to be done is by generating a random token that is broken up into pieces using XOR magic. Each factor in the auth process gives you access to one piece of that token. You combine those pieces back together using more XOR magic and, if your token matches the original token, you can proceed.

I asked this before to the HN community, but I didn't get much feedback; please share your thoughts. How come domain registrars have not developed this eons ago? [+] Isn't that arguably the most critical gateway for a community of web developers? I humbly ask these questions as an amateur and aficionado without any deployed commercial sites, so maybe the pros in here would beg to differ with my paranoia.

[+] Better yet, why doesn’t some HNer take up launching a security-oriented domain registrar? ;-)

It'd be nice they allowed 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.

You can generate application-specific passwords and then see/revoke those passwords on your google.com/accounts page.

Are these "application-specific" passwords limited in any way? For example, if one of them is stolen without my knowledge, can the attacker fully access my Google account (e.g. account settings, all Google services, etc.)? Obviously it's less likely that one of these passwords will be stolen than passwords, but it's still possible.

From the screenshots (don't have access yet) it seems that you don't get to specify the type of application or access, but I would assume there is some limitation on what you can do with these passwords?

Good question. I think app-specific passwords have full access.

If that's the case, what are they for?

Well, these services should be using OAuth by now anyway and we should not be encouraging them if they don’t.

That said, check out the “application-specific passwords” part of this offering. It may do just what you need.

Yeah, apparently they're going to have it for imap, but I'm hoping they include gtalk in there too.