Skylar, > Francisco, correct me if I'm wrong, but in your discussion > you assume that the application is incapable of keeping > secrets from the public (eg, mobile, desktop apps, etc.). > According to the spec, those applications should never > receive client credentials to begin with. They can't keep > secrets so they aren't issued any. Obfuscating secrets in > binary code doesn't count - if the tokens in question are > outside a secured firewall, they aren't secrets.
No, the application can be a traditional Web application with a client secret. > George's attack is a MITM attack which can be expensive or > difficult to pull off, but a possibility. At the least, it's > a security consideration of why a callback *should* use TLS. George's attack, and the ones I've been discussing, are easy to set up using hacker tools that can downloaded for free from the Web. When I first reported the issue back on January 3 I made an effort to explain how easy an attack can be. See the message: http://www.ietf.org/mail-archive/web/oauth/current/msg04894.html The attack scenario described in that message is slightly different from those discussed lately, but the practicality considerations are the same as for all the MITM attacks that have been discussed. > Someone speak up if George's scenario is flawed or I'm > misunderstanding it. My understanding is this: > > - Bob uses (web) client C to access provider P. > - Mallory has set up a MITM attack between client C and Bob's computer. > - Mallory also uses client to C and starts an an approval process from the > client to provider P > - Bob sends a request over HTTPS to provider P with client ID for C. > - Provider P responds to his request with a redirect to an authentication > code. > - Meanwhile, Mallory does not continue with the auth flow at provider P. > Instead, he waits for Bob. > - Bob's browser performs the redirect sent from provider P back to client C > (over HTTP). > - Mallory intercepts the clear-text request from Bob's computer and does not > pass the request on to client C. > - Mallory uses the auth code from Bob (and any state information) to forge a > redirect request to client C on his own session. > - Client C requests an access token from provider P for Bob's account using > it's secured client credentials. > - Mallory now has credentials for Bob on client C. Bob has a dead or invalid > auth handshake which was interrupted by Mallory (and not passed on to P to > avoid replay detection). I don't think this is what George said. Mallory does not to "start an approval process" at step 3. Francisco
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
