Paul Lindner: > Proposal number two I call "Tight User Binding". > > One issue with OAuth is that you are defacto granting access to your account > to an entire consumer key, which is generally an entire web site or client. > If a provider caches this authorization and automatically redirects to a > callback URL then an attacker can gain access without the end user even > knowing about it. (see the flowchart at twitter to understand how this can > be dangerous: http://apiwiki.twitter.com/Sign-in-with-Twitter) > > Instead of this blanket authorization we want to grant access to a specific > USER/CONSUMER combination. For an analogy look at the mysql grant > command. The current OAuth authorization pattern is similar to this: > > GRANT ALL ON localuser.* TO ''@'remoteconsumer'; > > You grant access to a consumer, not to a consumer/user pair. Instead we > want the equivalent of this: > > GRANT ALL ON localuser.* TO 'remoteuser'@'remoteconsumer' > > Remote user may mean different things depending on the consumer. For web > sites this could be a profile URL which, when fetched reveals the users > name/thumbnail url etc. I suggest leveraging microformats and/or link rel > tags. Sites without the concept of a user may have to use some other > identifier. > > For mobile or desktop clients, things are less clear. Perhaps simple user > identifiable information is sufficient. A delegated identity might be > required. > > To pass this information a consumer can send the identifying information via > an 'oauth_initiating_user' parameter when obtaining a request token. > > In either case we now have remote user information *and* consumer > information. The authorization screen will include this information, along > with a "That's not Me!" button. > > This doesn't stop all lines of attack -- an attacker could set up cloned > profiles that "look" like the remote user and attempt to get the user to > authorize. > > There's also a privacy issue. Perhaps the user does not want to share > identifying information with the consumer. However... As a provider I'm > very interested in binding accounts in the reverse direction, especially > partners where I have a bilateral agreement in place. (Again, this might > not be something that end-user desires...)
I'm a fan of this proposal. At its heart, the attack being discussed is social engineering; changing the flow (adding signing, limiting the variety of callback urls, etc.) is a way to mitigate (and mostly prevent) it, but when it comes down to it, it's a matter of trust. Focusing on the callback url is a bit of a red herring, as not all applications have callbacks (ignoring the proposal of splitting the flow for web/desktop apps). We're focusing on the B-C exchange where we should be trying to solve the A-B exchange. There's a "give a man a fish, teach a man to fish" proverb / joke here, but it eludes me at present. That said, the privacy issues can't be ignored, nor can the reality that some applications don't have the notion of identity. Also, if the attacker knows their victim's username, it becomes trivial to make it appear to be correct. I still believe that the approach is sound; instead of an identity, the consumer could generate a phrase (since this has a much higher likelihood of being unique and recognizable), display it to the user, pass the user onto the provider where they *should* see the same phrase. If they don't, they click the equivalent of the "THAT'S NOT ME" button and the authorization fails. Since that would be the end of the transaction if the identities don't match, arbitrary callback urls would remain an option. I was originally thinking that the identity/phrase should be passed directly to the authorization page (by making that a signed call which would obviate EHL's goal of elevating the use of Authorization headers), but I think you're right here: the identity/phrase should be bound to the request token upon issue. Leah Culver: > 1. One time only token exchange > > I actually agree with the suggestion to keep the access token endpoint > one-time only. This means that you only get one chance to exchange a request > token for an access token. > > At the access token endpoint, if the request token has been authorized, then > an access token is granted. If not, the request token is marked as invalid > or deleted. This means an attacker would get one shot to exchange the > request token (unknown if it's authorized or not) for an access token. > Pretty unlikely chance of success and probably not worth the trouble. This is an implementation suggestion, but I think it should make it into the spec as a MUST or a SHOULD. It doesn't solve the problem, but it eliminated the danger of brute-force attacks. > 2. No callback request parameter > > What about using a callback to guarantee a successful exchange? > > I'm a fan of eliminating the callback as a request parameter altogether. > Allow the consumer to register a callback when they register their > application. I've been trying to think of a scenario where a consumer would > want a dynamic callback, but I can't think of anything that can't be dealt > with (via a redirect) after the OAuth dance is over. MovableType plugins sharing a single consumer key/secret pair, identifying as "MT Plugin for X", installed on servers across the web. Think of them as desktop apps w/ the ability to register protocol handlers (but where the URIs must vary). I *like* my custom callbacks and would like to retain the ability to use them if possible. seth --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
