Forgot your password?
typodupeerror
Google Security Technology

Bypassing Google's Two-Factor Authentication 49

Posted by timothy
from the disclaimer-dug-song-is-a-genius-monkey dept.
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:
  • by F.Ultra (1673484) on Tuesday February 26, 2013 @11:56AM (#43014739)

    Since the regular password as been changed to require an additional two-factor password they of course had to come up with this ASP idea for services where you cannot provide a two factor authentication and of course these have to be more powerful than the password that you now changed into a two factor. How can this be a surprise at all?

    • by AvitarX (172628)

      Wasn't the single factor password to be tied to a device and a service though?

      I don't think it follows that it can obviously be used to disable 2 factor authorization (or even to get access to other services).

      • by Albanach (527650)

        Wasn't the single factor password to be tied to a device and a service though?

        The service thing I understand. I'm not sure how you would tie, say an IMAP password, to a device though? What would differentiate two different IMAP clients?

        • You just generate a password for each "device". You can have multiple IMAP passwords. It gets a little weird -- you can just keep cranking out passwords for your various devices. You just name them and then, if one is compromised, you delete it while keeping the others.
          • by Albanach (527650)

            I don't think you understand. How could Google identify one device from another?

            Of course as the user you can manage your passwords in whatever way works best for you. I don't see how Google could manage what the poster above suggested - that the password be tied to a device. From google's end, one IMAP client will look very much like another.

            • by AvitarX (172628)

              Agreed, I wasn't thinking, Google's apps (such as android gmail) could authenticate as a specific device cryptographically, but there's no way to hack it into unaware apps such as an arbitrary IMAP client.

            • I may have mis-typed. Google doesn't seem to care which generated password you use. You could just generate one password and use it for every single-factor login. Or you could generate a new one for every service. Either way, when you generate a password, you can "name" it whatever you want -- "Home Laptop Thunderbird IMAP", "SmartPhone Google Reader App", whatever. I don't think Google cares which one you use for which service. It allows you to name them for your own bookkeeping.
              • by icebike (68054)

                Actually TFA says the App Specific Password was encrypted with the device id. Google knows which device is talking to it.

                You are correct that ANY one of your valid ASPs could be used for any Google service. This is the part that they fixed.

                As you suggested, generating one single ASP and using it for everything would in fact work, but Google doesn't make this easy. You have to write them down somewhere, because once they show them to you, you can never see them again. You have to copy them into password

            • by hawguy (1600213)

              I don't think you understand. How could Google identify one device from another?

              By using the unique password to identify the device?

              Presumably Google has a password hash stored somewhere that they use to authenticate the device. If it matches password hash 1, then it's your phone, if it matches password hash 2 then it's your tablet.

              They could also use unique usernames, but that may be harder for the user. user+myphone@gmail.com for the user's phone, user+mytablet@gmail.com for the user's tablet. But some software will probably get confused and not understand that the authentication use

    • Re: (Score:3, Informative)

      by Anonymous Coward

      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-settin

    • 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.

      • by icebike (68054)

        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.

        But that was the part that they fixed, No?

    • by hawguy (1600213)

      Since the regular password as been changed to require an additional two-factor password they of course had to come up with this ASP idea for services where you cannot provide a two factor authentication and of course these have to be more powerful than the password that you now changed into a two factor. How can this be a surprise at all?

      Why does a device password have to be more powerful than my main two-factor protected password?

      If my phone needs a device password to download email, why should that password also be able to change my password settings?

      • by icebike (68054) on Tuesday February 26, 2013 @03:29PM (#43017285)

        From TFA:

        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 after username/password/2-step-verification prompt that you can’t skip.

        So, yes, you are correct, that is how it used to work, but not any more.

        Still these ASPs are not in fact "Application" specific. They probably should be, but that would be pretty convoluted and people would throw up their hands and walk away. (I read somewhere that something like 80% of the people that try 2-Factor give up when they see all the hoops that need jumping.

  • I considered the 'application specific' passwords as just 'hard for human to remember password' and that divulging the password to the program meant I explicitly trust the program with access to my account (the big fat clue being no app specific configuration data other than a helpful descriptive tag).

    I suppose they could enrich it by forbidding account management function, or scoping it more (e.g. mail versus jabber versus whatever as limited scope).

  • To be fair I can sort of see Google's point. An application specific password is meant to be given to the application once and then never typed again, heavily reducing the chance of it being compromised. It should still not be possible to turn off 2 step auth or change the users password with one though but I have never assumed that it couldn't. Google makes it quite clear that the password grants full account access.
    • by fermion (181285)
      I would say that this is far from clear. In chrome I was asked for my application specific password, but since I did not know what it was, and could find nothing to tell me, I did not give it or set it up. This really seems a case of bad security through complexity. When I log into Google, i give it my password and a one time code. This seems like simple security. Perhaps someone will tell me otherwise.
    • An application specific password is meant to be given to the application once and then never typed again, heavily reducing the chance of it being compromised.

      If it's kept in persistent storage by the application, that actually increases the chance of it being compromised. Rather than logging keystrokes or peeking at RAM or man-in-the-middling the application in some way, you can just read a file.

  • I use the Application Specific passwords as Device Specific instead. I have a code for my Phone, laptop, and desktop computers. So...If one of the devices gets stolen or sold, I just expire the one code. Much easier to manage 4 or 5 codes than a bunch of codes for a lot of apps.

  • I wonder if that is why I found myself locked out of my gmail account as of about 3:38 am yesterday. Fetchmail reported a password problem. I called google on that number from fastsupport, and 2 different people, neither of whom spoke English well enough to talk to this old Iowa Farm boy, tell me that something was changed in my account that only my machine could have done, and accused my machine of being compromised. I'm running linux, and my whole home network is behind a dd-wrt router. I can see the

  • OK, this is the best I could make out based on my limited understanding. You can turn on two factor authentication on and every time you log in from a browser, you need to get a code to cell phone or use a one time pad number as the second factor. But not all google accounts/applications/services use a plain browser to log-in. Looks like this is more common the apps/mobile/android world. So you create a special password for those applications alone. But if those app specific passwords are captured by a thir

I am a computer. I am dumber than any human and smarter than any administrator.

Working...