On Apr 24, 9:36 pm, Zachary Voase <[email protected]> wrote:
> I'd like to propose the following flow (which is basically an
> amalgamation of a few ideas throughout this thread):
>
> 1) User visits Consumer's website, Consumer gets request token
> from Service Provider.
> 2) Consumer sends user to the Service Provider's user auth URL,
> with 'oauth_token' and 'oauth_callback' as before but also
> 'oauth_signature' and 'oauth_signature_method' parameters.
> Alternatively, 'oauth_callback' may be omitted if the Consumer has pre-
> specified a callback URL with the Service Provider. Both of these
> methods prevent the attacker from spoofing a callback.
> 3) User logs in to the Service Provider (if necessary) and grants
> access to the Consumer.
> 4) Service Provider generates a nonce, and if the callback was
> specified (with either the 'oauth_callback' parameter or when the
> Consumer signed up to the Service Provider), the User is redirected to
> the callback with 'oauth_token' and 'oauth_callback_nonce' parameters.
> If no callback is specified, the Service Provider gives the User the
> nonce to enter into their desktop application, etc.
> 5) The Consumer then attempts to exchange the old request token
> for a new access token, including the 'oauth_callback_nonce' in the
> parameters for this request. This exchange may only be attempted once
> for a single request token, after which it will any subsequent
> attempts with the same request token will fail unconditionally. In
> addition, the callback nonce must be present and correct. Since the
> attacker in the session fixation trick doesn't know this parameter
> (and indeed *cannot* know this parameter), (he/she/it) cannot attempt
> to get the access token (which would originally have been done by
> visiting the Consumer's callback URL).
>
This seems like it addresses the the hole adequately as long as an
attacker that cannot manipulate the callback url cannot succeed (I
think that's true...).
Further thought on this whole thing makes me think that a one-time
only token exchange plus a non-modifiable callback are what's needed.
Maybe OAuth++ or somesuch can provide an extra authentication piece on
the front end for providers wishing to require that. Also, making it
very explicit on the provider's OAuth page that the user is
establishing an authenticated access agreement between the Consumer
app and the Service Provider that *they* own (i.e., are responsible
for, can revoke at any time,etc.). I also think (as I have said
before) that the spec should be explicit about the social engineering
exploits that are possible.
Somewhat counterintuitively, I realized that giving a user a link that
will then require them to log into a service is and will continue to
be quite common, esp. for application that use two-legged OAuth (i.e.,
any logged in user to this system has access to resources on this
other system). Expecting anything other than simple failure if it is
an exploit and seamless access if not would just not make any sense.
Making every effort to make an attack fail *after* the user
authenticates with the service PLUS explicit language on the SP OAuth
page is (I now think) the best way to go.
--peter
> In the case of a desktop application, the User would have the callback
> nonce displayed to them by the Service Provider and would have to
> enter it manually into the application. The Service Provider has the
> responsibility of making it *crystal clear* to the User that this
> should be kept secret. It's a lot easier to get the User to keep the
> callback nonce a secret than it is to get them to think critically
> about the Consumers they authorize.
>
> Can anyone find a security hole in this workflow?
>
> Regards,
> Zack
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
