On Apr 28, 2009, at 10:32 AM, Dossy Shiobara wrote: > > On 4/28/09 8:41 AM, Hubert Le Van Gong wrote: >> I also saw 2 additional ideas that might help >> (and are not necessarily exclusive with the 2 proposals): >> >> (3) Make Request tokens one-time only >> (4) Request that the user logs in at the Consumer before the request >> token request > > Requiring the user authenticate to the Consumer doesn't prevent the > attack, as the attacker is a legitimate user of Consumer in the attack > scenario.
Agreed. There are two parts - only one part is about both sides authenticating a user at their sites. The other part is the two parties (consumer and SP) agreeing that they are the same party (for the purposes of the protocol). One possibility is to (as was suggested by Nat) use a Web SSO protocol and base that trust (shared notion of user at both sites) upon: i) Web browser redirect-based protocols like OpenID and SAML ii) Passing an identifier between the consumer and SP, which they can both agree on. These steps are (in my opinion) neither part of standard OAuth itself, nor should they be, _explicitly_, unless we consider that for the purposes of adequate security for delegated authorization, it is required that both consumer and SP have a notion of identity, and can verify the identity of the user adequately (ie. via authentication). And this leaves open what would happen if the two parties don't or can't, a priori, agree on an identifier for the user (ie. if they don't support OpenID, or only support their own OpenIDs. One possibility would be to describe the problem in the security considerations of the specification, and mention that both the consumer and the SP may want to both authenticate the user adequately, and (perhaps even as an extension to the protocol) share an identifier that they could agree on. Making the user type a PIN (I forget who first suggested that) seems another plausible way, that may allow the consumer to avoid the notion of "identity" while maintaining adequate security. > What I keep proposing is that the user must authenticate at the > _Provider_ before the request token request. This would completely > eliminate the attack in the scenario. As others (Peter, Nat, Hubert at least) have said (and I agree with), either the user must essentially authenticate in _both_ places (perhaps by doing Web SSO between the consumer and SP, where the consumer simply trusts the SP to authenticate the unknown person who showed up at its website because it was done with HTTP redirects, and authenticates the user simply via an authentication assertion from the SP); and those authentications must be connected in some way by the consumer and SP, _or_ a mechanism should be used which allows the SP to indicate a "secret" to both the consumer and the user, and use the user to connect the authentication at SP with the request token issuance via the PIN. > And yes, making request tokens one-time only is a MUST, IMHO. It is certainly a security consideration which should be adequately explained. Regards, - johnk > > > -- > Dossy Shiobara | [email protected] | http://dossy.org/ > Panoptic Computer Network | http://panoptic.com/ > "He realized the fastest way to change is to laugh at your own > folly -- then you can let go and quickly move on." (p. 70) > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
