On Apr 23, 11:05 am, Bruno Pedro <[email protected]> wrote:
> Hi,
>
> We (tarpipe) have been thinking about the problem for a while and we
> think we have a solution.
>
> So, here's our proposed solution (against OAuth Core 1.0
> —http://oauth.net/core/1.0):
>
> 1- In §6 (OAuth Authentication Flow diagram), add two optional
> parameters to step A (Consumer Request Request Token) preventing the
> man-in-the-middle attack when used together: oauth_callbak and
> oauth_challenge;
>
> 1.a- The oauth_challenge should be saved on the Consumer side and
> associated with the user initiating the request — by using session
> storage, for instance;
>
> 2- In §6 (OAuth Authentication Flow diagram), add one optional
> parameter to step D (Service Provider Directs User to Consumer)
> preventing the man-in-the-middle attack: oauth_challenge;
>
> 3- The Consumer, instead of providing the oauth_callback on step C,
> provides it on step A along with an optional oauth_challenge which
> should be saved on both the Consumer and Provider applications;
>
> 4- The Provider, instead of relying on the oauth_callback from step C,
> will rely on the one coming from step A and will redirect the user to
> that URL using an optional oauth_challenge GET parameter if one was
> provided on step A;
Does this add the extra burden on the Provider of maintaining state
between A & C (i.e., being able to "remember" callback from A)?
Currently, it is the Consumer secret that ties these interactions
together. Again it is addressing the need to connect the action/user
in A with the action/user in C -- to "mix it in" with the out-of-band
understanding established in the consume secret.
>
> 5- The Consumer will then check the oauth_challenge that comes from
> the redirect on step D against the one previously provided on step A
> and will only complete the transaction if both values match;
>
> 6- The Consumer will immediately destroy the oauth_challenge on its
> side, preventing future requests coming to the same URL.
>
> Advantages:
>
> a- It's impossible to create a man-in-the-middle attack by forging the
> oauth_callback parameter because it's being sent behind the scenes on
> step A and the Provider doesn't rely on the one being sent on step C;
>
> b- It's also possible to detect such attacks by checking if the
> oauth_callback parameter is being sent on step C and if it's different
> from the one on step A — the attacker won't know if the Consumer is
> sending the oauth_callback on step A and will try to forge it on step
> C;
>
> c- It's impossible for the attacker to keep trying to finish the
> authorization process on the Consumer side (steps D and eventually E)
> because he/she needs access to the oauth_challenge that was provided
> behind the scenes on step A.
>
> We hope it helps getting to a solution. Let me know about it.
>
> Best,
> Bruno Pedro
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
