Slashdot Mirror
Bypassing Google's Two-Factor Authentication
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!"
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?
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?
Application-specific passwords are for programs that don't support Google's 2-step authentication process. They're computer-generated (approx 16 characters of random alphanum) and you're supposed to use one per application. I use one for Mac Mail, one for YouTube posting on my iPhone, etc.
Clearly they bypass the 2-step auth process because that's what they're designed to do. So how are these not working as designed? I can see that it would be better if they could be restricted to say only allow YouTube posts or only allow IMAP access, but that's a design improvement.
Did I miss something here? Are they broken as designed or is the issue just the design?
...and I'm a customer who uses this functionality.
I'd really need a much better explanation to know what part of this is a bug. Letting application-specific passwords leak is a problem, and has always obviously been such -- part of the reason OAuth2 is being positioned as a replacement is to avoid having these tokens stored.
Just keep in mind that any application that has access the files on your computer (mainly the browser cookies) can bypass the 2-factor-auth. You just need to copy the cookie to another browser and BAM! - you're logged into Google.
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).
XML is like violence. If it doesn't solve the problem, use more.
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.
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!
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.
"If you have done 6 impossible things this morning, why not round it off with breakfast at Milliways" -- hhgg
Why the block quotes? Was this cleaned up from something offensive or unintelligible?
that good security is a process, NOT a product.
You're still struggling to understand? Reread the article and my previous comment. The fact that Google fixed the issue should indicate to you that, it was in fact, real despite your comprehension issues.
The application specific password allowed access to services and areas that it should never have. That access removed all security measures. This may or may not have been by design, but if it was by design, the design was broken. That's why they fucking fixed it, you moron!
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 traffic leds on both the switch and the router, and this machine isn't spewing anything.
I've run all the usual suspect tests for rootkits and such, and I am confident my machine is clean. The only thing that might be suspect is the "by country" logs from awffll. India shows up to a much larger extent than I would normally associate with running a repo for a nearly 30 year old computer originally sold by Radio Shack. 31% of the traffic, a grand total of 1.33Mbytes, (I said its a legacy machines repo), was to/from India. No PHP involved either.
So, since I have more than one 'isp' at my disposal, I spent a good part of the day yesterday re-subscribing to the mailing lists I am on from a different address that is not under google's ever so helpful umbrella.
I am quite tired of the 800 lb gorilla's in this "intertube" thing passing the f*cking buck when _they_ get a fart stuck crossways.
Cheers, Gene
So if I had not created any app-specific password I should be safe right? Or have I implicitly created some app specific passwords to let my android phone to log in to my google account? I don't have any serious app in my mobile phone. All I do with my phone is to make phone calls, listen to FM radio and look at the clock. Why I got a smart phone I don't know. Now it looks like it is making my google accounts vulnerable.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
I think you're being over-critical of the commenter's diligence. There is some room for interpretation or confusion. Yes, application specific passwords are intended to provide single-step authentication to applications that don't participate in 2-step authentication. And yes, it's easy to gloss over the distinction between using an ASP to access application functions versus security aministration functions, and that's where the bug lies. Its easy to gloss over because ASPs were intended to replace 2-step authentication, and its a somewhat subtle point that this access should exclude administrative functions - subtle because that was never mentioned in the design/purpose of ASPs.
So I think the commenter's confusion/question is fair to some extent: Google representatives themselves probably glossed over the distinction between limiting ASP access to app-level functionality versus ASP access to admin-level functionality leading to their initial response that it was working as intended. Now you say that the commenter should have made that distinction, and that's true with the help of this article, but there's still a gray area that I think the commenter is trying to point out. Not only is there a distinction between app-level access and admin-level access that ASPs should have been conscious of. There's also a distinction between app-level access and app-specific access. In other words, an application could be limited to access only data relevant to its specific operation (just email content, for example), or it could be limited to access only data relevant to *any* application-level operation (exclude all admin functionality, but allow access to all other data), or it functions just like a mechanism to bypass 2-step authentication, accessing all functionality (which Google now agrees is "buggy").
The commenter acknowledges that yes, it would have been nice to have ASPs limited to app-specific functions, but notes that this level of refinement was never intended to be incorporated into ASPs. And I think the commenter is right on that point. My (and your) response to that however is the next level of distinction. This is not the level of distinction being called out in the article. I think the distinction is between app-level access versus admin-level access, not a reference to app-specific access. No application should have admin-level access when using an ASP. That's less of an enhancement and more of a security flaw when you get to that level of security hole.