4 ms·

> 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 OA

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

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