Heads turned Wednesday when Twitter turned off its popular new authentication service, which uses the emerging OAuth web standard. The real story soon broke that someone exposed an OAuth security exploit that would let unauthorized users access a victim's account using a phishing scheme.
The exploit was found on a bet during last week's Foo Camp, a conference-like gathering for hackers put on by tech publisher O'Reilly at the company's campus in California. One particular attendee decided he could find an exploit in OAuth.
"It's just a new use case nobody thought of before," said Eran Hammer-Lahav, OAuth's designated community coordinator for this threat. "The initial response is: this is an authorization, not authentication. You shouldn't use it for that, and I kept saying because I'm a big fan of the Twitter sign-in solution, 'Well, show me an exploit.'"
Determined to find an exploit, the hacker (who prefers to remain unnamed due to the terms of his employment) targeted OAuth. The hacker found that if he started a request, then directed a victim to initiate the authorization form on his behalf from a bogus trap site, the victim would submit the login form and provide the hacker access to the victim's data.
Hammer-Lahav wrote up a very detailed description of the exploit on his blog.
The exploit only affects new users of an application. If you've already authorized an application yourself, this exploit will not jeopardize your account.
OAuth's official acknowledgement was released Thursday.
The good news is the exploit was found before it was used on any other use case than Twitter. The bad news is that once the exploit was discovered, OAuth experts realized other OAuth partners weren't safe either. Because around 75% of OAuth adopters were gathered at Foo Camp by luck, the primary shareholders all agreed on a course of action to take to minimize damage.
Minimizing damage, in this instance, means making it as hard as possible for hackers to take token authentications and send them to users. This means turning OAuth off entirely (a la Twitter), limiting the time it takes to authenticate the session dramatically, or put up a warning on authentication questioning the source of the link (if the link did not come from the application itself).
In response to the exploit, Hammer-Lahav acknowledges the OAuth protocol will need to be revised. The new specification will not be backwards-compatible. Hammer-Lahav says this is the direction OAuth must take immediately.
When asked whether this security exploit will hurt OAuth's future, Hammer-Lahav thinks it will actually do the opposite.
"This has been a solution that has been reviewed for a year and a half now, and it has been reviewed by most well-known security experts and they just missed it. Nobody ever thought of this particular security exploit. There's nothing to suggest that if you create your own proprietary platform, you're not going to make the same mistake or a different one."
"I think the way the community behaves around it and the way it was addressed will really show that, you know what, this is a mature community that can respond to this situation in a mature and effective way."
There aren't very many security methods that have escaped exploits. The lessons learned from this exploit actually provide a good indication of how OAuth can adapt to inescapable flaws. According to Hammer-Lahav, OAuth has taken away a lot from this situation.
"We need to look at how we handle this and do a post-mortem on this entire process. -- not now but in a few weeks -- and come up with a process on how to deal with this. One of the things that we did not have was a list of providers that have OAuth so when there is an exploit you will be notified."
There's a lesson here for all open-community specifications. There is a fair amount of organization that is inherent to proprietary communities that aren't available to organizations without a governing body.
"Next time it happens to OAuth or OpenID or any community-driven specification, we actually have resources [to address the problem]. For us it was really hard to find those resources," Hammer-Lahav says.
He also claims the usual security resources or organizations were not equipped to help OAuth. "They don't really help you unless you're a vendor or a software provider. But if you have a spec that's broken, there isn't really an infrastructure to deal with it."
See Also:
