In a wordy article that could have been much shorter and a lot less sensational, Ryan Paul of ArsTechnica throws mud mostly at Twitter, but saves plenty to throw at OAuth. Unfortunately, Ryan Paul (who clearly is a smart guy) is heavy on the accusation but light on the arguments. Typically, I would go over this article an item at a time, but I’m right in the middle of draft 11 of OAuth 2.0 which is a much better use of my time. If you want to read a great rebuttal, Ben Adida’s response (as always) is a great read.
The OAuth standard has many significant weaknesses and limitations. A number of major Web companies are collaborating through the IETF to devise an update that will fix some of the problems, but it’s still largely a work in progress. The current version of the standard—OAuth 1.0a—is an inelegant hack that lacks maturity and fails to provide clear guidance on many critical issues that are essential to building a robust authentication system.
First, the current version of the standard is RFC 5849. The RFC not only changed a lot of the terminology, highlighted the known security limitations, and has completely new prose, it also explicitly clarified at least one of the author’s issues regarding the handling of timestamps (which most companies don’t even bother to check anyway).
My favorite silliness from the article, when discussing the lack of specification details about using client secrets in installed applications:
Part of the problem is that the specification doesn’t provide much guidance about what implementers should do instead, which has forced them to improvise. Facebook and Google Buzz have both come up with reasonable solutions and offer desktop-appropriate OAuth authentication flows that do not require a secret key or require the end user to go through a complicated copy/paste process.
The specification is very clear (as the article quotes) – don’t use client secrets in installed applications! The reason why the specification doesn’t say much more is because there is no solution. It does not exist for a distributed application unless you issue a different secret to each installation. To say that Facebook and Google came up with reasonable solutions is pure sensationalism. What is their reasonable solution? They don’t use client secrets. In other words, they do exactly what the specification says.
The article does bring up important points implementers should pay attention to when using OAuth, such as the secrecy of their client credentials, the exact details of their user experience, how they authenticate the user (cookies, etc.), and an overall awareness to phishing. But OAuth, just like other security protocols, is designed to be implemented by security experts. In addition, there are simply no widely available solutions for many of these problems.
If Twitter uses the client secret in installed application for anything other than gathering statistics, well, they should reconsider. But it’s not like they have other alternative. That’s the only valid “news” the article has to offers.
It’s easy to throw mud without getting dirty with making a fully baked technical argument – and it makes for a fun read too. But when it comes to a widely deployed security protocol, scoring page views by scaring readers about security is not fair game. It is always valuable to highlight OAuth’s weakness, but in context, with the right security risk analysis, and with clear comparison to other alternatives.
I expect more from ArsTechnica.
Liked this post? Follow this blog to get more.