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!"
Where's the surprise? (Score:5, Insightful)
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?
Surely this is expected (Score:2, Insightful)
Re:Nice Guys! (Score:5, Insightful)
The generally accepted behavior is to:
1. Report the bug to the developers.
2. Work out a disclosure timeline and give them time to fix the problem.
3. Disclose after the fix is released.
Except when the developer at stage two says; 'that's not a bug' or, 'that's intended design', or FOAD' or they ignore you completely. Then the responsible thing is to disclose the bug so that everyone knows that it is an issue and stops using the service until the developer is forced to address the issue.
In this case, Google said that it was by design. Meaning essentially that there was no fault/bug when there clearly was. At that point, with no expectation of it being fixed, Duo Security would have been well within the right to disclose and force Google's hand. Or, they could turn evil and profit from the exploit, since you seem to feel that they should not have disclosed a bug that Google was ignoring.
Re:Nice Guys! (Score:1, Insightful)
They're a Google Ventures company.
Best not to bite that hand that feeds you.
Re:You Didn't RTFC! (Score:4, Insightful)
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.