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