 |
 |
The thing this conversation (and Twitter) is missing, is that the OAuth protocol neither requires nor relies upon each piece of client software having a key of any kind. Twitter wants it to, so it can disable "a certain application" (distributed and used by many people) if they decide that app is misbehaving. But that's not part of OAuth's security model, really, that a client-identifying key gets revealed does not in fact compromise the key parts of OAuth's security model. Trying to know if a given piece of software on the network is "really" a copy of "Application X" is not, so far, a solvable problem. Compare, it's the exact same problem that a video hosting website might want to solve only letting "their" application (which is distributed to end-users) access their videos, and not some other application impersonating it. You can try to make it hard by obfuscating the protocol or the keys, but someone can always reverse engineer it because, you're distributing your application (and any embedded keys) to users. OAuth doesn't try to obfuscate it, that's not OAuth's domain. [ You can also try to make _illegal_ what you couldn't make technically impossible, that's what the DMCA does, but that's not OAuth's domain either]. On the other hand, instead of trying to confirm that a client on the network is "really" a copy of "Application X", if you try to confirm that the person _using_ that client knows certain secrets that only a user of your server knows -- _that's_ feasible, and that's what OAuth does. Ideally via redirecting the user to the server to enter credentials and be redirected back (the same model Shib uses, I say 'ideally' cause it's the best anyone's come up with thus far, even though it has problems with phishing suceptibility). But OAuth (at least 2.0) has other workflows supported too, for when you can't do that (say, you're a Wii application and not a web browser). Jonathan Nate Vack wrote: > On Mon, Sep 20, 2010 at 4:21 PM, MJ Ray <[log in to unmask]> wrote: > > >> I think FOSS servers would be affected by the published-key spoofing >> flaw too, wouldn't they? >> > > They would, but it should be easy(-ish) for each server admin to get > their own key, which it can then (hopefully!) keep secret. The real > problem is getting end-users to generate, enter, and register a > consumer key. > > Really really, though, just treat the consumer key as a user-agent > string. Don't take it seriously. You are free to not make the same > mistakes as Twitter; your needs are different. > > Cheers, > -Nate > >