Hi Breno and Simone, I disagree. I believe that in order to perform a MITM attack against properly implemented 1.0a, the MITM would need to intercept the response *and* be able to prove to the consumer that it is the user that originally requested access. In other words, it would have to already own the user account on the consumer, meaning that a MITM attack would not be necessary at all.
By "properly implemented", I mean that the consumer application checks that the user who is redirected back to the consumer is the same user that initiated the authentication request, usually by requiring the user to be logged in at the callback URL. Looking back at the spec, this is probably not clear in the body of the spec, but is addressed in the security considerations section. For example: http://tools.ietf.org/html/draft-ietf-oauth-web-delegation-01#section-8.6 Ethan On Fri, Sep 25, 2009 at 10:48 AM, Breno de Medeiros <[email protected]> wrote: > > Hi Simone, > > Yes, interception is possible. Note, however, that the URL to return > the user to is signed in the consumer's initial request, so it is not > possible to mis-direct the user. So to intercept the response the > attacker needs to perform a Man-in-the-Middle attack. Typical > protections against MitM can then be used (e.g., use SSL at the > provider and consumer endpoints). > > > > On Fri, Sep 25, 2009 at 7:46 AM, Simone <[email protected]> wrote: >> >> Hi. I would ask you a thing about the unguessable parameter >> oauth_verifier. >> In the attack at the core 1.0 specification the intruder not have to >> intercept anything but only constructs a link for the victim. >> In the new version of the protocol core 1.0A, when the service >> provider redirects the user to the consumer with the parameter >> oauth_verifier, if an intruder intercepts this message with the >> oauth_verifier, since the message is in clear, cannot the intruder use >> the oauth_verifier and come back him to the consumer for continue a >> previous session of the protocol, realizing an attack similar to the >> that found in the core 1.0 specification? Is there the assumption that >> the message in the redirection (from the user to the consumer) is not >> intercepted? >> Sure the attack is more difficult than the first one because now are >> need some interceptions, but is possible, or not? >> > >> > > > > -- > --Breno > > +1 (650) 214-1007 desk > +1 (408) 212-0135 (Grand Central) > MTV-41-3 : 383-A > PST (GMT-8) / PDT(GMT-7) > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
