Twitter recently ditched its Basic authentication method for OAuth authentication, which is intended to be more secure, but Ryan Paul at Ars Technica believes OAuth is inherently flawed and that Twitter has done a botched job at implementing it, making it an even greater security threat.
In a strongly worded diatribe Paul said the OAuth standard “has many significant weaknesses and limitations”, calling it “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.”
He said that websites have to “tread carefully” and come up with ways to fill the gaping holes in OAuth. This, in turn, means there is no consistency in how websites implement the standard. Facebook and Google also use it, but Paul said “Twitter’s approach is, by far, the worst.”
A key problem Twitter faced is trying to prevent accounts being compromised through the use of third-party applications. There are over 70,000 Twitter applications out there, all of which previously required users to enter their login and password under Basic authentication, which the applications stored. This led to thousands of account details being stolen and hacked, creating a security nightmare for Twitter.
The answer to this was found in OAuth, as this authentication standard does not store passwords. Many applauded the move and Twitter said “the move to OAuth will mean increased security and a better experience.” Paul believes there is a fatal flaw in how Twitter is implementing this, however.
OAuth requires a set of keys, called a consumer key and consumer secret, as part of the authentication process, but Twitter is requiring that all Twitter applications embed the keys within the applications, which means that an attack on the application itself could result in the keys being discovered and the private details of users exposed.
Paul said that Twitter’s move is “against all reason” and revealed why it decided to opt for this less secure route: “Twitter wants to use the keys as an abuse control mechanism to centrally disconnect spammers and other unwanted users of the service.” Since OAuth was never designed for this reason major vulnerabilities are being exposed to make this function work.
He demonstrated how the attack could be done by using Twitter’s official application for Android. He played around with the code and found the keys in the APK, which he said was “trivially easy” to do. Access to these keys allows authentication to any Twitter account using that application, creating a huge threat to the security of all Twitter users.
Eran Hammer-Lahav, one of OAuth’s developers, wrote a rebuttal to Paul’s criticisms, rejecting them as “sensational” and “nonsense”. He said that Paul is “heavy on the accusation but light on the arguments.”
Hammer-Lahav said that many of Paul’s concerns about OAuth itself have been addressed in the current version of the standard, and the specification recommends not to use the consumer key and secret within installed applications.
“If Twitter uses the client secret in installed application for anything other than gathering statistics, well, they should reconsider,” he said, revealing that Twitter is implementing OAuth in a way that the specification advises against.
TechEye spoke to Stefan Tanase, Senior Security Researcher at Kaspersky, who would not comment on how good Twitter’s implementation of OAuth is, but told us how secure the authentication standard is in general and how Twitter has adapted to security threats in the past.
“OAuth is certainly a better way of using 3rd party apps than giving your username and password to a developer you usually know nothing about,” he said. “Any security aware user would definitely think twice before sharing their login credentials with a 3rd party, and most likely will refuse to do it.
“The truth is though that most of the users, let’s face it, are not security experts. It’s hard for me to think that the average Twitter mommy or granny would consider the implications of giving their login credentials to a 3rd party developer before using an application. So in the end, I don’t see how this last move Twitter just did is not to be applauded. I consider it to be a step forward – and you know, when a baby starts making his first steps, you don’t really care how long his steps are. You’re just happy to see the baby going the right way.
“And it’s been like this since Twitter got mainstream. I still remember the days when the Twitter log-in form would send the username and password without using HTTPS. And when the website started to be targeted by spammers and malware writers, Twitter realized they need security – so they started making progress in this direction. There were many incidents on Twitter during all this time – I’m sure people remember the XSS worm, or when the Koobface worm started targeting Twitter also. Sure, probably the speed of improving things could have been better, but Twitter has certainly been doing a good job.
“As for comparing the security implications of using Twitter apps or the Twitter website directly – I’d certainly go for using the website directly if I could be sure the transport layer is secure – no public or insecure WiFi networks, for example. Whenever you add one more intermediary, the 3rd party apps in this case, you expand your vulnerability surface. So in this case, the less, the better. But as it always was and always will be, security and usability are two things that don’t really go hand in hand. Twitter, the developers and the users need to reach some sort of an equilibrium point between these two – if you want to increase your security, you most likely have to give away some of your freedom (usability in this case).”
With no answer in sight, it appears that Twitter has mended one hole in its application authentication process, only to open another elsewhere. Security experts are divided on how secure OAuth is and how well Twitter is implementing it, but only time will tell just how big that potential threat really is.