Nat Sakimura wrote: > On Tue, Apr 28, 2009 at 11:32 PM, Dossy Shiobara <[email protected]> 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. >> >> 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. >> > > Right. I think I have seen something like this on this list recently, > but the problem is in this wholesale grant model. > > Let S:=Service Provider, C:=Consumer, V:=Victim, A:=Attacker, > S:V:= User V at S, S:V:Data := Data of user V at S, C:* := any user in C. > > Then, what OAuth does right now is: > > [1] Get Permission on (Grant access on S:V:data to C:*) > > by misguiding the user as (Grant access on S:V:data to C) > > This is not pretty. It is illegal in many countries (not in U.S. though.) > > And, what you are proposing is to deny the wild card in [1] above and > make it explicit, so that it will be like: > > [2] Get Permission on (Grant access on S:V:data to C:A) > > which, I think, is a good idea. > > Under this scenario, in the last vulnerability that we encountered, > the victim will be asked to grant permission to C:A, which, he > probably would not. > > But isn't the issue that there is no way for C to communicate A to S in a way that V can determine their being "attacked"? One of the principles of OAuth has been that it works without identity federation (i.e. that S doesn't need to know about V's identity at C nor C know about V's identity at S).
It's possible for C to send the requesting user's "identifier" to S (in the request_token request) for presentation to the user during "authorization" at S, but then there is a leakage of identifiers that could lead to privacy/correlation issues. This has been suggested by a number of others as a good UX enhancement but not "solving" the technical problem. Note that this also presumes that the user must first be authenticated to C before starting the OAuth flow. Thanks, George > =nat > > > > >> And yes, making request tokens one-time only is a MUST, IMHO. >> >> -- >> 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 -~----------~----~----~----~------~----~------~--~---
