6 ms·

Compromising Twitter's OAuth security system

85 points by abraham 16y ago

dododo 16y ago
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 16y ago
  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.
  - dododo 16y ago
    i agree it makes sense for web apps. 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.
  - caf 16y ago
    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.
  - deleted 16y ago
    [deleted]
bond 16y ago
"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 16y ago
  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 16y ago
    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 16y ago
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 16y ago
  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.
  - deleted 16y ago
    [deleted]
  - pak 16y ago
    > 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.
jallmann 16y ago
> 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/ http://oauth.net/about/
- tptacek 16y ago
  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 16y ago
    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 16y ago
      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 16y ago
        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/965d471cb39fac6d 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.
credo 16y ago
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.
tptacek 16y ago
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 16y ago
  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.
konad 16y ago
> my opinion of Twitter is less positive how positive was it when they used GET ?

85 points by abraham 16y ago

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 16y ago
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.
- dododo 16y ago
  i agree it makes sense for web apps. 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.
- caf 16y ago
  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.
- deleted 16y ago
  [deleted]

bond 16y ago

"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 16y ago
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 16y ago
  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 16y ago

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 16y ago
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.
- deleted 16y ago
  [deleted]
- pak 16y ago
  > 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.

jallmann 16y ago

> 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/ http://oauth.net/about/

tptacek 16y ago
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 16y ago
  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 16y ago
    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 16y ago
      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/965d471cb39fac6d 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.

credo 16y ago

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.

tptacek 16y ago

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 16y ago
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.

konad 16y ago

> my opinion of Twitter is less positive how positive was it when they used GET ?