

Compromising Twitter's OAuth security system - abraham
http://arstechnica.com/security/guides/2010/09/twitter-a-case-study-on-how-to-do-oauth-wrong.ars

======
tptacek
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.

~~~
sp332
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.

~~~
tptacek
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.

~~~
caf
Availability is a security property too.

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.

~~~
tptacek
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.

~~~
caf
They've _said_ they will, which is good enough for me.

I agree that the headline is misleading.

------
bond
"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...

~~~
sausagefeet
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.

~~~
barkingcat
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"

Something like that would help.

------
pak
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.

~~~
tptacek
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.

~~~
pak
> 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.

------
dododo
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.

~~~
tptacek
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.

~~~
caf
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.

------
credo
_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.

------
jallmann
> 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/>

~~~
tptacek
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".

~~~
caf
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?

~~~
tptacek
Either you're looking at a different, older OAuth spec or you too are quoting
it out of context, because the spec provides examples.

~~~
storm
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/...](http://groups.google.com/group/twitter-development-
talk/msg/965d471cb39fac6d)

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.

------
konad
> my opinion of Twitter is less positive

how positive was it when they used GET ?

