Bypassing Google’s Two-Factor Authentication

The most interesting and clarifying takeaway for me was the revelation that with 2-factor auth enabled (which I've had for some time now), the Application Specific Passwords were actually <i>more</i> privileged than my actual account password, considering my account password required a second factor of authentication to work, assuming my device wasn't "remembered for 30 days".<p>The thing that's always annoyed me is the way that Google allows ASPs in some places but not in others, particularly when an application uses OAuth. Consider this:<p>A 3rd-party app uses OAuth to access your Google account. Great!<p>You install the app, fire it up, and the first thing the app does is prompts you to authenticate the app. It takes you to Google's OAuth screen to approve the app. This often happens within a popup window in the app, not your actual browser, which means you're not logged into your Google account, so the first thing you're presented with is a Google login form.<p>Now, this is a popup window with no URL visible, so how do I know that this is actually Google's form on their server? And even if it is, how do I know the app isn't using some embedded JavaScript to sniff my credentials?<p>Not wanting to take a chance, I head over to my browser and create a new application-specific password to enter into the login form, knowing that I could easily revoke it if I change my mind. I enter the ASP in the app's popup Google login form, and lo and behold I'm greeted with the message "Please enter your account password and not an Application Specific Password here."<p>Turns out Google returns a message when you're using an application-specific password prompting you to enter your actual password. Now they've set that precedent. Now any app can simply code up a form to look like Googles, throw it in a popup, and put that message in there after the first time you submit the form to make sure they get your account password (of course, doesn't matter for me, because they don't have my second factor, but it would matter for the majority of people, who don't have 2-factor auth setup). If you didn't enter an ASP the first time, you'd just assume you mistyped or mis-pasted your actual password the first time, and enter it again the second time. Now they can be sure they have your actual password.<p>Of course, all this would have been moot if the ASP was more powerful than the actual password to begin with, but it seems like after Google's fix, this is back to being a problem.

I had this vulnerability cast into sharp relief recently through my Apple ID compromising my contacts. I sync my Gmail and Gmail contacts via IMAP to my iPhone and iPad using application-specific passwords. Both devices are backed up on iCloud. When my Apple ID was compromised the crook restored my iCloud backup to a new device, complete, to my horror, with the application specific passwords, which were used to stream out my contacts.<p>New devices and novel data requests do not revoke application-specific passwords which, as the article notes, are anything but specific. Also, Apple's security support is a 24-hour round-trip via an email technician.

I reported this to Google about the same time, in June last year, and got a similar response. Interestingly, I published some notes on the issue almost exactly one week before the duosecurity researchers 'discovered' it ;)<p><a href="http://grkvlt.blogspot.co.uk/2012/08/google-tfa-security-issue.html" rel="nofollow">http://grkvlt.blogspot.co.uk/2012/08/google-tfa-security-iss...</a>

As an early google two step user, i've often wished those application specific passwords would bind to the first property that they're used for. From what I understand their current layered service architectures for some products makes this difficult for them to pull off.<p>For better or worse, google two step authentication is primarily to mitigate shared passwords, phishing and kiosk style keyloggers.

The problem doesn't seem to be the ASP itself, but the failed (OAuth-like?) implementation.<p>"- OAuth tokens are created automatically, while ASPs are a thoroughly manual affair"<p>"- OAuth tokens use a flexible authorization model, and can be restricted to accessing only certain data or services in your account. By contrast, ASPs are — in terms of enforcement — not actually application-specific at all!"<p>Well, there's your problem. Application <i>Specific</i> Password isn't very specific at all.

Interesting read as bypassing the same thing was needed for this hack: <a href="http://blog.cloudflare.com/the-four-critical-security-flaws-that-resulte" rel="nofollow">http://blog.cloudflare.com/the-four-critical-security-flaws-...</a>

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?

I enabled this at some point in time, it's amazing how many services I use that rely on Google. After I got over 20 application specific passwords, which I guess are tell alls, I decided it wasn't worth the complication. The real problem with this was apps implementations of the two-factor auth. I haven't looked at any of the APIs (I know they don't exist for some services like Reader) but if the entirety of the auth was only typing in a code sent to your phone I would've stuck with it. It's when you get into these application specific passwords, especially when you have to create new ones on your phone, that I think it's more trouble than it's worth.

Google's authentication schemes can be incredibly confusing, and they're something I've had to deal with while building an unofficial client to Google Music [0].<p>Here are two things worth knowing (that are somewhat covered by the article):<p>* aside from OAuth, any method of client auth is basically equivalent to SSO (ie, your entire Google account). As noted in the article, this includes app-specific passwords<p>* SSO is not meant for programmatic access. If you want code to have access to SSO credentials, it's easiest to use some other auth service, and then "upgrade" to SSO (the linked blog post describes one way of doing this) [1]<p>[0] <a href="https://github.com/simon-weber/Unofficial-Google-Music-API" rel="nofollow">https://github.com/simon-weber/Unofficial-Google-Music-API</a><p>[1] <a href="http://nelenkov.blogspot.com/2012/11/sso-using-account-manager.html" rel="nofollow">http://nelenkov.blogspot.com/2012/11/sso-using-account-manag...</a>

Realizing its a usability nightmare, these things really should be able to be tied to a service. ASP for email, bind to smtp and imap, nothing else. ASP for chat, only works with xmpp, etc.

&#62; We think it’s a rather significant hole in a strong authentication system if a user still has some form of “password” that is sufficient to take over full control of his account.<p>I don't really understand this sentence...they say that Google (post-fix) no longer enables access to security-specific pages unless you do two factor auth, so doesn't that mean that post-fix you <i>cannot</i> fully take over someone's Google account without two factor auth?

So the security risk requires someone to somehow get your ASP? Correct me if I'm wrong, but I believe you can only make a new ASP when you are already signed in and it disappears after you 'hide' it or leave the page. It kind of seems like if you can get a user's ASP, the account is probably already compromised.<p>It's nice that they are fixing a couple loopholes, but not sure if it will actually help any.

FYI - I had also observed some similar issues which I recently presented at a security conference. (The conference talk happened to be the impetus for Google to fix this stuff when they did.) For my perspective on the issues, please check out my conference slides: <a href="http://connect.ncircle.com/t5/VERT-Security-Research-Blog/Hats-off-to-Google-for-breaking-my-app/ba-p/8106" rel="nofollow">http://connect.ncircle.com/t5/VERT-Security-Research-Blog/Ha...</a>

At some point I'm going to give up using what everyone else uses. That will solve this problem once and for all, because no one will know or probably care what I'm using.

Apparently nobody mentioned it yet but TFA talks about the "timeline" and ends up saying that, two days before publicly reporting, Google did change something (after all, after saying for 6 months that the exploit was an expected behavior):<p><i>"2013/02/21: Fix is pushed by Google to prevent ASP-initiated sessions from accessing sensitive account interfaces."</i><p>So is that one particular hole describe in the article / blog fixed or not!?

What are you guys doing with all of these ASPs? I used to need them but I don't have <i>any</i> ASPs registered on my TFA setup right now. Chrome and Android both support the TFA flow now and have for a while.

I made a hosted api solution for easy two-factor/google authenticator (similar to what lastpass and stripe are using) integration here <a href="https://www.gauthify.com" rel="nofollow">https://www.gauthify.com</a> Its designed to integrate into the google authenticator app since many big players are already using it (SMS &#38; Email option too).<p>With that aside I want to make it clear that the ASP aspect of Google Authenticator was bypassed and RFC 6238 (<a href="http://tools.ietf.org/html/rfc6238" rel="nofollow">http://tools.ietf.org/html/rfc6238</a>) timecode based two-factor authentication is still as solid as they were when it was written (I had a false sense of urgency to read this when I read the title).