On Apr 26, 8:29 pm, Peter Keane <[email protected]> wrote:
> On Sun, Apr 26, 2009 at 7:11 PM, Brian Eaton <[email protected]> wrote:
>
> > On Sun, Apr 26, 2009 at 11:42 AM, pkeane <[email protected]> wrote:
> >> I would just mention that this proposal (essentially making the
> >> callback url immutable)
>
> > a) that proposal does not make the callback URL "immutable".
> > Consumers and SPs can both mess with it. It just makes sure the user
> > at the browser doesn't mess with it.
>
> Sorry -- I meant an attacker could not change it.
>
> >> limits the likelihood that the user who
> >> authenticated w/ the SP is NOT user who requests an access token, it
> >> does not actually verify that it is the same user.
>
> > 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 wiki page states 6.8: "The Service Provider MUST check that the
> OAuth verifier was originally issued for the OAuth consumer key and
> request token." But in the described exploit, the attacker has both
> the consumer key AND request token. The unpredictable callback token
> needs to *also* rely on a "user identifier" to be secure. Since the
> consumer does not have a notion of identity, "state" must be saved
> either on the SP or on the user him/herself between user
> authentication and granting of access token. The problem here (and
> why this is so difficult) is that the attacker has access to the
> "secrets."
Sorry -- I got this last part wrong. Simply saving state on the SP
does not solve the issue. Ther user would need to actually assert a
SP-based identity (not necessarily a password) know only it the user
for this to work. Ugh - back to squre one. Some sort of user PIN
(displayed to them upon successful AuthN w/ SP and entered by them
when requesting the access token would work).
--peter
>
> I would note -- a requirement that the SP keeps a store of the
> unpredictable callback token (assuming user identifier is mixed in)
> and checks it before granting the access token DOES make this
> "verifyably" the same user.
>
> --peter
>
>
>
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
