Hi Breno, True, and I'd forgotten about that nuance.So I suppose consumers/clients should no longer relying on cookies at their callback URLs, but actually requiring the user to log in again over a protected connection (outside of the OAuth flow).
I'm starting to think that there might not be enough guidance on this topic in the actual spec as there are a lot of places that a client/consumer implementor can still go wrong and appear to be in compliance. I'm cc'ing the IETF list, as it seems that would be the forum to get further guidance into the spec. Ethan On Fri, Sep 25, 2009 at 1:03 PM, Breno <breno.demedei...@gmail.com> wrote: > Hi Ethan, > > I agree with the assessment, i.e., that XSRF protections can in theory > prevent against interception attacks. In practice, however, a MitM attacker > would typically have access to cookies and so in practice would 'own' the > user's account at the consumer already. No matter how you look at it, a MitM > attacker is too powerful a scenario. > > On Fri, Sep 25, 2009 at 10:39 AM, Ethan Jewett <esjew...@gmail.com> wrote: >> >> 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 <br...@google.com> >> 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 <simonx...@hotmail.com> 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) >> > >> > > >> > >> >> > > > > -- > Breno de Medeiros > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
