On Apr 23, 5:00 pm, Zachary Voase <disturb...@googlemail.com> wrote:
> I don't know if I've misunderstood things, but just to clarify - there
> *isn't* an issue of an attacker getting hold of an actual access token
> itself, because the request for the access token is signed with the
> request token secret (which an attacker has no access to).
>
> But basically, I've tried to break down the problem into a couple of
> basic ideas about trust.
>
> 1) We need to make sure that, if present, the oauth_callback parameter
> was generated by the consumer. This can be done easily by including an
> additional parameter oauth_callback_signature with the callback
> parameter signed by the consumer secret and request secret; that's the
> whole point of HMAC. Maybe an additional
> oauth_callback_signature_method parameter could be included with the
> method (i.e. HMAC-SHA1 or HMAC-RSA, etc).
>
> 2) The following sentence is a monster: we need to ensure that the
> user who initiated the consumer's request for the request token is the
> same as the one who's authorizing it on the provider. This is a much
> harder problem to solve, because it means we have to bridge the gap
> between user accounts on the consumer and provider, whilst making any
actually, I would say you need to make sure the person initiating the
request is the same person initiating the authorization. It needn't
be tied into actual user accounts. As far as I understand, consumers
might not even have a notion of "user" beyond session state. That's
why I had suggested PIN, but....
> solutions feasible for non-HTTP/HTML systems. Unfortunately, at first
> glance, it seems an intractable problem, which cannot be solved
> without a fair amount of work on the user's behalf. This is the real
> 'social engineering' problem; a PIN probably won't work, because if I,
> as a malicious user, can convince someone to authorize a service to
> use their account, then I can probably just give them a PIN and ask
> them to enter it. However, there are still ways of reducing
you have a point there (about social engineering attack convincing
victim to enter a PIN). There must be some other way to store state
in initiating user's brain :). Really, I think that's what it comes
down to.
> uncertainty, which is what any protocol revisions or provider
> recommendations should tackle.
>
> So how can we ensure that the request token user is the same as the
> authorization user? We can begin by making sure that the request token
> is authorized within a short period of its requesting. This can be
> done purely on the provider side, but where some consumers may wish to
> cache request tokens, this might not be optimal. So a consumer could
> stamp its user authorization URL with a nonce and timestamp, and sign
> it all, enabling the provider to verify that the user auth URL was
> presented within a sensible amount of time. For example:
>
> http://provider.example.com/oauth/authorize?oauth_token=foo&oauth_cal...
>
> So it's a bit of a beast, but it jumps the hurdle of ensuring that
> authorization requests were made within a sensible amount of time. In
> fact, any important parameters in the user auth URL should probably
> also be signed by the consumer. This makes sure that attackers are
> incapable of spoofing authorization parameters (which no doubt is an
> important issue in and of itself).
>
> In addition, as has already been suggested, it could be configured on
> the provider such that when a consumer tries to exchange a request
> token for an access token, if that request fails, the request token is
> put on a blacklist so that it will not be usable again, whether for
> authorization or exchange. In addition, a timeout could be specified
> on the exchange, such that if the exchange is requested a long time
> after the token is authorized, it fails. So what might happen is this:
>
> * Malicious User (MU) visits consumer site or uses consumer
> desktop app and gets a user auth URL with a request token.
> * MU gets Ignorant User (IU) to click on user auth URL and
> authorize the third-party application.
> * If the consumer is a web app, then the user will be redirected
> to the callback URL (which has been signed, so it cannot be spoofed).
> The consumer then gets a request at the callback URL, and tries to
> exchange the request token for an access token. This is successful,
> but one of two things should happen: consumers should either realise
> that the request token was fetched for another user and signal an
> error, or it should associate the new access token with IU instead of
> MU. An alternative behavior would be unacceptable, but there's nothing
> anyone can do to stop evil or ignorant consumer implementations (a
> consumer could, for example, decide to share their entire database of
> access tokens and consumer key/secret pair). Luckily, that's why OAuth
> is good, as access can be revoked.
> * If the consumer is a desktop app, then a few things might
> happen. MU could start brute forcing the access token, which would
> lead to one of a couple things:
> 1) They would start too early and invalidate the request
> token.
> 2) They would start too late and the request token would time
> out.
> 3) They would ask for an exchange just at the right time and
> get access.
> The last of these is the dangerous one, but also the least
> likely to happen. An exchange timeout of 5 seconds, for example, would
> be able to mitigate most attacks; a good idea would be for the
> provider to keep the timeout secret to prevent people from getting in
> towards the end of the Goldilocks period. Don't forget that it will
> also take some time for MU to convince IU to click the authorization
> link.
>
> Alright, so that's a less-than-brief summary of my ideas on reducing
> the severity of this issue; at its heart it's not one that can be
> easily solved by just introducing a few more parameters, because it
> has to do with people, not computers. Hope someone can gleam some
> value from this.
>
> Regards,
> Zack
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
