I do hope that you can't get in just by knowing someone's mother's maiden name, though...
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.
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".
"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. ;)
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.
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.
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.
Yeah, </sarcasm>. But it's still a big improvement.
1 - hard copy code printout (optional)
2 - failover to secondary phone (optional)
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.
[+] Better yet, why doesn’t some HNer take up launching a security-oriented domain registrar? ;-)
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?
That said, check out the “application-specific passwords” part of this offering. It may do just what you need.