On 4/28/09 8:20 PM, Nat Sakimura wrote: > 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.
Actually, in my proposed scenario, C:A can only try to get S:A:Data. They can't generate a way to trick V into authorizing C:A's request for S:V:data in the first place. In my proposed change, even with the Consumer key and secret AND the request token and secret being fully disclosed to the Attacker, the attacker cannot generate a request that would let the Victim authorize the token so that the Attacker could convert it to an Access Token for the Victim's data at SP. -- 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 -~----------~----~----~----~------~----~------~--~---
