Please create an account to participate in the Slashdot moderation system


Forgot your password?
Google Security Technology

Bypassing Google's Two-Factor Authentication 49

An anonymous reader writes "The team at Duo Security figured out how to bypass Google's two-factor authentication, abusing Google's application-specific passwords. Curiously, this means that application-specific passwords are actually more powerful than users' regular passwords, as they can be used to disable the second factor entirely to gain control of an account. Duo [publicly released this exploit Monday] after Google fixed this last week — seven months after initially replying that this was expected behavior!"
This discussion has been archived. No new comments can be posted.

Bypassing Google's Two-Factor Authentication

Comments Filter:
  • You Didn't RTFA! (Score:4, Informative)

    by Anonymous Coward on Tuesday February 26, 2013 @12:14PM (#43014993)

    You missed the part where your individual ASP doesn't simply have access to YouTube, but rather to ALL of your Google services. And, worst of all, the ASP also gave full access to the password/account options page so, you could leverage an ASP and take complete control of all services managed by that Google account.

    A single ASP completely bypassed all security and two factor authentication.

    This was all clearly and plainly explained in the not-very-long fucking article!

  • by Anonymous Coward on Tuesday February 26, 2013 @12:20PM (#43015077)

    Well, a session using an ASP should not be able to do things that an app has no business doing, such as visiting the account security page. Google seems to understand this:

    This is no longer the case as of February 21st, when Google engineers pushed a fix to close this loophole. As far as we can tell, Google is now maintaining some per-session state to identify how you authenticated — did you log in using a MergeSession URL, or the normal username, password, 2-step verification flow? The account-settings portal will only allow you to access security-sensitive settings in the latter case (i.e. if you logged in using a MergeSession URL, it will give you a username/password/2-step-verification prompt that you can’t skip.)

  • by Talennor ( 612270 ) on Tuesday February 26, 2013 @12:31PM (#43015201) Journal

    It's a privilege escalation problem. The surprise was that changing your main password or password recovery email should be only done by the full account, not an ASP context.

  • Re:Nice Guys! (Score:5, Informative)

    by icebike ( 68054 ) on Tuesday February 26, 2013 @02:48PM (#43016779)

    So, Google blows them off and the don;t go public for seven months? These are some nice guys!

    Or perhaps they've been profiting for the past seven months. WFT Google?

    Well, its not as easy as to pull off this exploit as it might seem.

    From TFA:

    So: given nothing but a username, an Application Specific Password, and a single request to [], we can log into any Google web property without any login prompt (or 2-step verification)!

    So you had to know two things:

    1) Someone's Username
    2) Someones Application Specific Password.

    You had to know their PASSWORD. Or you had to "set up an an intercepting proxy with a custom CA certificate to watch the network traffic" to try to capture the encrypted password". These ASPs are encrypted with the sending device id. (That Device ID is yet another thing that the attackers KNEW up front. If you didn't know that Device ID, setting up the Intercepting Proxy wouldn't help you.

    Granted if you know the password its game over. Two factor authentication only works if every piece of software supports it, and until it does big long hairy App specific passwords still have to be used.

    You can't derive this password unless you also know the device ID, because its encrypted.

    The big HOLE here is that ANY one of your valid Application Specific Password gave you access to ALL parts of your Google Account.
    So an ASP for SMTP allowed you to access your Account dashboard. They really weren't Application Specific on Google's end. That is the part Google fixed.

    But again, its not as big of a gaping hole as the summary makes it out to be. Because you still needed to carefully craft an intercepting proxy, know the originating device id, decrypt the password, and log in VERY QUICKLY because the encrypted password is date stamped with a short life span. This would be very hard to pull off in the real world.

    So yeah, it needed fixing.
    I'm glad its fixed (for the most part), but there was no giant emergency here.

VMS must die!