"I repeatedly attempted to make Twitter aware of the problems with its OAuth implementation, but the company largely ignored my concerns. When I opened a support ticket, it was promptly closed and I was directed back to the developer mailing list, where I received no response from Twitter after writing several posts outlining my concerns. My attempts at responsible disclosure were unsuccessful."
How can they do a good job if they won't even start listening to developers trying to help them...
Just because they didn't listen to the OP doesn't mean they don't listen to other developers. Where I work we often cycle between customer-facing development and backend, we ignore what we aren't working on at the time and even then we have to prioritize.
But even if you were going to prioritize, it would make sense to send a note back saying "we're aware of the situation and will work on it as time allows"
This is a wildly editorialized and misleading article.
Here is the gist of what Ars Technica is saying: the OAuth "consumer secret" exists as a sort of obscured "user-agent" string, a "hint" to Twitter about what client you're using. Because end-users can usually recover the consumer secret easily by basic reverse engineering techniques, there's no security in them, and therefore they shouldn't be relied on for anything.
Well, almost. But before you get there, note what Ars Technica hasn't reported: anything an appsec professional would term a compromise in Twitter's OAuth security system.
The issue here isn't that attackers can violate OAuth security. It's that Twitter may want to use the OAuth consumer secret as a way to revoke OAuth access to suspect applications. The claim here is that devious malicious people will steal the consumer secrets from popular native applications, abuse them in some overtly scammy way, and get those native apps cut off from Twitter.
That's maybe true as far as it goes, but it ignores the fact that Twitter would face this same problem in a myriad of other ways even without OAuth. It also shellacs Twitter for the failings of OAuth, which was intended to facilitate cooperating web applications, where the consumer secret really does provide some benefit, because it's hidden on web servers that attackers can't readily access.
(Incidentally, native app developers can simply keep consumer secrets on their own servers, which seems to me like using OAuth the way it was designed to be used, rather than as magic cross-platform authentication pixie dust, which it simply isn't).
Has Twitter done everything right here? Probably not. They're the ones promoting OAuth as the preferred standard auth method. The documentation could be clearer as well. But nothing they've done merits an article that suggests they've fielded a bona fide security flaw because of how they handle OAuth.
The rest of the claims in this article --- particular the last page's worth of complaints about obscure errors --- be aware that when it comes to (psuedo-)crypto authentication protocols, it's pretty easy to get dinged for having distinguishable error messages. The best practice is: be as vague as possible whenever possible. At best, Twitter could maybe do a better job with error reporting on a staging server developers could use to prove out their OAuth support. But that's hardly a news story.
I'm prepared to be wrong about anything here. But I think Ars got this one wrong.
He spoofed Twitter's first-party app on Android. If a spammer does the same, Twitter's only recourse is to revoke the key and make everyone download a new version of the app. This is a trivial way to cause a lot of damage for Twitter, and a lot of headaches for their users.
It's obvious on it's face that it's possible to "spoof the Twitter Android app". You'd need something a lot more interesting than OAuth to prevent that. What's his point?
What this article is really about is distaste over a policy decision Twitter appears to have made, which is that they may revoke consumer secrets for applications that end up associated with scam apps. We can argue over the merits of that decision ad nauseam, but I'll short circuit it (again) by pointing out that Twitter would have had the exact same problem without OAuth; they'd simply be attacking it in an ad hoc way instead of with OAuth.
I have two huge problems with this article:
* It sensationalizes an issue that isn't about security, but rather is about developer-friendliness. Of course, since (as far as I can tell) no major Twitter app has been disrupted by this unfriendliness, this story wouldn't have had legs without the scary security spin they gave it.
* It throws the baby out with the bathwater on OAuth, which again simply isn't intended to be a universal authentication protocol for native apps. Near as I can tell, everything Twitter's doing makes perfect sense for web apps, which I'm guessing are still far and away (by usage) the most-used customers of Twitter's API.
The article isn't really saying there's a security problem in OAuth alone, but that there's a security problem in the overall system consisting of OAuth, Twitter's mandating use of it in a way it wasn't intended, and Twitter's presumed policy of disabling "compromised" keys.
Has Twitter actually shut down any application anyone's heard of with this policy, or is this just scaremongering?
Because, again, Twitter has a variety of ad-hoc means at its disposal to block clients without going anywhere near OAuth.
Meanwhile: "using OAuth in a way it wasn't intended" is not the same thing as a "compromise" in Twitter's OAuth system. And yet thats the headline of the article.
Any authentication situation where there is a distributed secret is fundamentally broken. Unless every app developer runs their own proxy that holds the secret key, and then validates incoming requests from their users before forwarding them on to Twitter, OAuth can't be expected to validate that a particular client was used to send a request. End-users of the app could be validated by their product key or similar (individual secrets). Obviously running a proxy is not practical for every app maker but it's already being used for a lot of situations (e.g. IM clients with push on the iPhone).
I don't think there is any protocol besides PKI with client-side certs that can guarantee authenticity of the client from the API's perspective. The app developer registers a secret key with Twitter, and uses it to sign individual certificates for each user that buys their app. Twitter can then verify from the certificate that it is receiving a request from user X using client Y made by the app developer.
No. Any authentication situation where every end user needs to protect a secret shared among many end users is fundamentally broken. That's not the same as what you just said.
OAuth works well for web apps. OAuth works less well for native apps. It's not "fundamentally broken"; it's just been stretched past its design limits in iPhone/Android settings.
The other side of this is that OAuth does backflips to work within the limitations of browsers and web applications. Native clients have much better options than OAuth for strong authentication. As a result, there's much less need for a standardized shared authentication protocol for native apps; OAuth actually doesn't make life much simpler for end-users or app developers than most "interesting" web services auth protocols already are.
This problem absolutely does not require a PKI to solve.
> No. Any authentication situation where every end user needs to protect a secret shared among many end users is fundamentally broken. That's not the same as what you just said.
OK, I was imprecise in my language. You clarified what I meant.
> This problem absolutely does not require a PKI to solve.
How would you solve it for native apps? By "it" I mean enabling the API to be sure that user X submitted the request with app developer Y's real client. Without having the app developer sign something for every user downloading the client, or running a proxy.
the DRM-like application keys leads to some obvious underhand scenarios.
if the app key is compromised, the key is revoked and no twitter access. if you extract the twitter oauth key from a competitor's desktop/android/iphone/etc app and post it on the internet, twitter will kill your competitors twitter application until they distribute a new key. rinse + repeat.
i wonder if twitter will revoke their own app key.
If you're saying it's "DRM-like" to have a problem that requires software protection to try to solve, I understand this comment.
But if you're saying that Twitter's OAuth scheme is inherently DRM-like, no, it isn't. It makes perfect sense for web apps, and it's been shoehorned into native apps, but the core problem Twitter is dealing with (how can we shut off malicious clients) is totally orthogonal to OAuth or DRM.
The whole concept of remotely distinguishing "malicious clients" from "perfectly cromulent clients" is quite DRM-like. It's analgous to the problem of distinguishing authorised video screens from unauthorised video duplicators.
but for apps installed in developer-untrusted environments, using app keys (and requiring their "protection"--good luck with that) is reminiscent of the dvd/bluray shenanigans.
This is because the purpose of the OAuth standard was to mitigate the password antipattern, not to holistically solve every security problem.
Since none of the other comments have anything favorable to say about Twitter OAuth, let me make the point that it does accomplish its primary goal
I agree with the writer that OAuth doesn't create a absolutely fool-proof way to authenticate the app itself. However, in terms of authenticating the user, it does much better than the old basic auth scheme (where some apps ended up sending passwords over HTTP).
So Twitter OAuth is a security win from a user perspective.
> Twitter's approach to OAuth is obviously misguided, but it gets even crazier when you compare the company's implementation against the actual standard. The OAuth specification itself describes the secret key security issue and says explicitly that implementors should not do what Twitter is trying to do:
That's embarrassing, considering Twitter's prominent role in designing the original OAuth specification. http://oauth.net/about/
No, it's not embarassing, because Ars quoted the specification out of context. It doesn't say "don't use consumer secrets to authenticate clients"; it says "don't only use consumer secrets to authenticate clients".
Ars quoted the entire relevant paragraph. It says "Accordingly, Service Providers should not use the Consumer Secret alone to verify the identity of the Consumer."
The confusing part here is that "Consumer" here means the application, not the Twitter user.
So how else is Twitter verifying the "Consumer" (being the application itself) other than the Consumer Secret?
OAuth 1.0, RFC5849, April 2010: "if the client is a desktop application with freely available source code or an executable binary, an attacker may be able to download a copy for analysis. In such cases, attackers will be able to recover the client credentials. Accordingly, servers should not use the client credentials alone to verify the identity of the client. Where possible, other factors such as IP address should be used as well."
I strongly agree with your criticism of this article, but that is pretty clear. And Twitter does freely and clearly acknowledge that a "determined attacker" can snag the secrets from a given app. But they still want to have it both ways. They counsel obfuscation (even though an attacker will observe your secret without bothering to understand your obfuscation method; time spent on "best effort" here is clearly time wasted). They counsel doing things like "using the API through a homebrew proxy that actually holds the keys", which they immediately hedge by stating that they are "not actually recommending these avenues"... http://groups.google.com/group/twitter-development-talk/msg/...
In the end, their "not actually recommended" path of pushing everything through a key-bearing proxy sure looks like the only way to develop desktop and mobile Twitter apps without taking a risk that the following chain of events will occur (and, as someone mentioned, maybe even be set into motion by a competitor): key disclosure, key revocation, app breakage, scrambling to get updates out, unhappy users + lost revenue, etc.
As you say, the problem of "how can we shut off malicious clients" is orthogonal to OAuth. But Twitter is choosing to involve a part of OAuth that is easily compromised in desktop/mobile contexts in solving that problem anyways.
How can they do a good job if they won't even start listening to developers trying to help them...