Bypassing Google’s Two-Factor Authentication • Hacker News Board

Re: Bypassing Google’s Two-Factor Authentication

#51

Post by sbronstein » Mon, Feb 25, 2013, 9:57 PM UTC

marshray wrote: post #28

sbronstein wrote: post #20

> 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. 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 cannot fully take over someone's Google acc…

I think the "still" was meant to refer to "after the addition of the 2nd factor to the auth process" rather than "after the fix to the vulnerability described here". It's making the case that this does represent a "real" vulnerability, even if certain aspects of the behavior were understood and expected by the system designers.

Yeah after re-reading I think you are correct. And yes, I certainly agree that it was a real vulnerability!

Re: Bypassing Google’s Two-Factor Authentication

#52

Post by bigiain » Mon, Feb 25, 2013, 10:16 PM UTC

sneak wrote: post #45

rdl wrote: post #40

Earlier quoted context omitted.

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.

Re: Bypassing Google’s Two-Factor Authentication

#53

Post by dpeck » Mon, Feb 25, 2013, 10:35 PM UTC

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.

Re: Bypassing Google’s Two-Factor Authentication

#54

Post by [deleted] » Mon, Feb 25, 2013, 11:24 PM UTC

grkvlt wrote: post #5

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 ;) http://grkvlt.blogspot.co.uk/2012/08/google-tfa-security-iss...

[deleted]

Re: Bypassing Google’s Two-Factor Authentication

#55

Post by martinced » Mon, Feb 25, 2013, 11:25 PM UTC

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

"2013/02/21: Fix is pushed by Google to prevent ASP-initiated sessions from accessing sensitive account interfaces."

So is that one particular hole describe in the article / blog fixed or not!?

Re: Bypassing Google’s Two-Factor Authentication

#56

Post by drivebyacct2 » Mon, Feb 25, 2013, 11:50 PM UTC

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

Re: Bypassing Google’s Two-Factor Authentication

#57

Post by inopinatus » Tue, Feb 26, 2013, 12:05 AM UTC

trotsky wrote: post #8

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. For better or worse, google two step authentication is primarily to mitigate shared passwords, phishing and kiosk style keyloggers.

I confess I was misled by the name "application specific" into assuming that such a binding already occurred.

Re: Bypassing Google’s Two-Factor Authentication

#58

Post by trotsky » Tue, Feb 26, 2013, 12:40 AM UTC

JangoSteve wrote: post #43

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 more 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". The thing that's always annoyed me is the way t…

Once you've downloaded and installed a native application and plan to grant it access to your google account you've decided you trust the application. If you install a malicious app and give it credentials it can fuck you about 50 different ways, even if there is a url bar indicating you're on a google.com server.

Any app that takes a ASP would otherwise be storing your main account password. Two step is still improving your security posture here - your main credential can't be used without the temporal pin so the ASP is actually much more valuable.

If you're still concerned about a native popup, just don't enter your correct password the first time. If it fails you're probably pretty safe - Phishing style credential captures usually won't pass it through and risk server side anomaly detection.

Re: Bypassing Google’s Two-Factor Authentication

#59

Post by trotsky » Tue, Feb 26, 2013, 1:05 AM UTC

drivebyacct2 wrote: post #56

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

I think you must be on a testing channel - it's still a hard to find flag that defaults to off on stable, and it wasn't more than a few months ago that it sat broken for weeks and finally got yanked for a time.

also - 3rd party mailers and xmpp clients.

Re: Bypassing Google’s Two-Factor Authentication

#60

Post by eropple » Tue, Feb 26, 2013, 1:07 AM UTC

drivebyacct2 wrote: post #56

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

A number of applications still don't. I have three ASPs for Pidgin and Adium on different devices, one for Reeder on my Mac, one for Beejive on my iPad, etc. Also, Chromium on my Linux netbook doesn't seem to support TFA, either.