This attack actually wouldn't work against Google if you are using Chrome due to its built-in hard-coded HSTS list.

http://dev.chromium.org/sts

http://www.rodneybeede.com/Protecting_against_MITM_and_sslst...

I'd always thought that the application specific passwords would allow for a loophole, although I hadn't come up with a mechanism.

Surely the fix from Google would be pretty simple? Just make sure that any and all access to the 'Two Factor Authentication Settings' page required a two factor token. I thought it already did, but I've just tried it and the OP is right, you just need a password.

If the attacker is SSLstripping the connection, two-factor auth wouldn't help much - the attacker is already between the user and Google, and could present the (second) two-factor prompt for accessing the settings page e.g. as a "login failed" page.

Yes, you could MITM the attempt to load the settings page, but it would require Alice to be attempting to load the settings page. This is a MUCH rarer activity than just opening her inbox.

I think Piskvorr is saying that you could trick Alice into entering the code for the settings page from her email inbox. Once Bob visits the settings page and gets to the two-factor prompt, he pops up a javascript box in Alice's gmail inbox like "Oops, something went wrong with your authentication. You have been sent a new code to enter here: [ ]" Alice says "WTF Google?" and enters the second code, and Bob grabs the code and uses it to access settings.

But even if we assume that Alice is totally hosed once Bob completes a MITM attack, I think you're right that there needs to be two-factor auth to create an app-specific password. It wouldn't protect from MITM, but it would protect from watching over Alice's shoulder, keyloggers, and all sorts of other ways that Bob might get Alice's password without being MITM.

(Edit: Google does require two-factor auth to access www.google.com/account and generate new app-specific passwords, doesn't it? I thought it didn't when I first tried, but that's just because I've already authorized this computer. If that's the case, then I'm inclined to believe that Google has done all it can do. If an attacker controls your secure communications with Google's server, you are out of luck period. If an attacker only has your password, then two-factor auth will keep them out of your email like it's supposed to.)

Yup, just what I was trying to say. Thank you for laying it out in greater detail and more clearly than I've managed.

Note: this is basically "a practical application of SSLstrip". Once you are capable of pulling that off, full control of the ssl-stripped site is a lesser concern. Interesting (and perhaps juicier as a media soundbite than "OMG SSLstrip exists!"), but not groundbreaking.

Yeah, I wasn't trying to focus so much on SSLstrip, but rather that it's possible to get into an account that has Two-Factor enabled, and generate a OTP that will allow for sans Two-Factor logins going down the line.

Weakest link gets attacked - and with one-factor auth still available, that is the weakest link. IMNSHO, labeling this scheme as "two-factor" is misleading - "two-factor with possible backdoor" would be more appropriate. (Also, I think that "OTP" is more commonly used to mean "one-time pad" - now that would have been more secure :))

This is a big "duh" to me and I see very little value in this post.

As far as Google's control extends, I can't think of anything they could implement without flaws that wouldn't be hostile to most of their end users.

If it weren't this flaw, it'd be a "zomg, I can plug a USB key into Alice's computer and install a keylogger".

This is a trivial, routine style of attack and of course it will work against Google's security scheme which is catered towards the everyday Joe and Alice and designed more to protect against phishing.

A better scheme where if you lost your phone, you lose your data forever, would not pass muster with everyday users.

The best response from Google that could happen here is that they implement a notification feature as to when a OTP is generated.

Physical access and tampering is conspicuous and suspicious. Rogue-twin WiFi AP is inconspicuous, and few users would suspect anything is amiss.

Reading up on SSLstrip, it looks like it relies on intercepting links and redirects sent over plain HTTP to rewrite them to something you control. So could this be defeated by authentication baked into the browser that would only send your credentials over HTTPS to a pre-specified domain? I know Mozilla was working on authentication in the browser.