On Mon, Apr 27, 2009 at 11:33 PM, Josh Roesslein <jroessl...@gmail.com> wrote: > Peter, > > Couldn't we verify the user on the consumer-side during the callback URL > redirect (user returning from SP after authorization)? > This callback URL has two pieces of data: > - Callback secrete: generated by SP after user authorizes consumer > - Request token: publicly known, so could be forged by attacker > Plus we can do this callback with https to prevent man in the middle attacks > on the wire. We are using https to exchanges passwords with the SP, so > if https was vulnerable in some way, we have already lost the fight since > the attacker now has our SP password. > > As long as the consumer links this authorization with the user during this > callback phase, the attack can not do a session fixation. > When consumer goes to fetch access token, it can only do so with the request > token and the callback secrete. > Since only the authorizing user can know this callback secrete, an attacker > can not complete this callback phase. > > Consumers should NOT bind request tokens to accounts. This should only be > done during callback. > This way even if the attacker generated the request token URL using their > consumer account, it is not bound to any account yet. > This only occurs during the callback phase which only the user can do. > > I think this provider a verifiable means to link the user's consumer account > with their SP account with out having to do any pin exchanges. > We could do a manual exchange of the callback secrete (so its like a pin) > that the user manually enters into the consumer. This way there is no way > a man in the middle can see this value. Consumer will know this is the right > user when it fetches the access token (which will fail with invalid value) > and the SP > will know its valid since the incoming value from the consumer matches what > it gave to the user. A social attack could be used to make user > share this value. With proper education we can help minimize this, but not > totally prevent it. This is why I don't like the pin approach, it leaves it > opens us up for another > social attack. By invisibly passing this value via a https callback, a > social attack is blocked. >
Hi Josh- All of the strong/secure parts of the OAuth spec are built on previous arrangements (out-of-band): the consumer-SP registration, and the SP user authentication mechanism. Both of those are vulnerable to social attacks, but those are out of scope for OAuth (and should be). You are correct that a manual exchange of callback secrete provides the "verifibility" that we need. I don't think a social attack is likely, either, since that secret is only created upon user authentication at the SP (i.e., too late in the game for the attacker to get at it). Of course, it should be a once-and-only-once validity and for a limited time period, but it does ensure verifiable identity. --peter > On Mon, Apr 27, 2009 at 10:25 PM, pkeane <pjke...@gmail.com> wrote: >> >> >> >> On Apr 27, 10:11 am, Brian Eaton <bea...@google.com> wrote: >> > On Sun, Apr 26, 2009 at 6:29 PM, Peter Keane <pjke...@gmail.com> wrote: >> > >> b) that's what the unpredictable callback token is for. >> > >> > > Does that demonstrate it is the same user? I believe it makes it >> > > highly likely, but not "verifyable" (in standard authentication terms. >> > > Nothing is 100% verifyable). >> > >> > The request token provides linkage from the consumer to the service >> > provider. The callback token provides linkage in the opposite >> > direction. If the consumer proves possession of a matching request >> > token and callback token, that's excellent evidence that no session >> > fixation attack is occurring. >> >> Hi Brian- >> >> Certainly, it is excellent evidence. But I worry about not having a >> verifiable linkage. The linkages that OAuth leverage are as follows: >> >> 1. The consumer and the SP have a shared "out-of-band" secret >> (consumer pre-registration). That allows the consumer to tell the SP >> "hey it's verifiably me" (by way of the request token). >> 2. The user and the SP also have a shared "out-of-band" arrangement >> -- SP authentication -- that verifies the user is verifiably who they >> say they are. >> >> Note that those are both based on "out-of-band" arrangements. There >> is actually no link to tie the user to the consumer, except for >> tokens, parameters, etc., but those are all "in-band" and so are *not* >> verifiable. That last missing link is necessary for verifiable >> identification of the u...@consumer. A simple PIN or somesuch would >> do it. >> >> I'm happy with OAuth for the typical sorts of social networking, >> photo-sharing, etc. use cases, and I use it for that. But I'd very >> much like to be able recommend it for more highly secure scenarios >> here on campus (I work in higher ed) that might involve confidential >> records. For OAuth to replace or be used in conjunction with the >> cuurent campus SSO and federated systems like Shibboleth, we would >> really need that extra level of verifiable security. >> >> --peter >> >> >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
