On Apr 24, 5:31 am, Zachary Voase <[email protected]> wrote:
> I've read all of the messages on here up until now, and so far (to
> summarize) there have been three main points which have been repeated
> quite a few times:
>
> 1) If you're going to specify a callback, you've got to sign it
> (otherwise the consumer can pre-specify it at the SP)
>
> 2) SP-generated nonces / callback nonces / callback tokens
>
> 3) One-time-only exchange requests (i.e. the request token is
> invalidated after the first attempt to exchange it for an access
> token)
>
> The first and last ones I get and I think we're all in agreement that
> they're a good way of plugging some of the holes in the spec; the
> second still seems a bit iffy, I don't quite get it as yet but from
> what I can tell it means the user has to go SP => consumer => SP =>
> consumer, and it also seems relatively insecure. The whole vector of
> this attack is social engineering so, as I said previously, if the
> attacker can convince the user to authorize (her/him/it) then (she/he/
> it) can probably also convince the user to enter a PIN.
>
> I've probably got it all wrong with the callback nonce, so could
> someone please explain how the flow of the callback nonce would work,
> and (if you're feeling really nice :-) how it significantly improves
> security? Just because I haven't seen a concise summary yet, and the
> ideas are littered all over the place.
>
I'm not 100% sure this is the bit you are talking about, but...if you
can assure that the user initiating the OAuth handshake is the same
user authorizing the request token (i.e., having been refered to the
SP, "authorizes" interaction) the particular attack in question is
prevented. It's the A-B part of the equation refered to earlier.
There are a number of ways to address it: 1. have the user enter a PIN
at the consumer that is mixed into the request token & that the SP can
then ask them to verify, 2. put some sort of notice at the SP
explaining to the user not to authorize if they were not the one who
initiated the interaction, etc. I am not sure if the "callback
nonce" suggestions were addressing this same need or not.
I seems the consensus is to not address this part in depth since it
impacts user experience negatively. It might be good, though, to
explain the issue, suggesting possible remedies and leave a real
authentication mechanism (which might require the consumer to
authenticate the user before initiating a handshake w/ the SP) to an
extension (?).
--peter
> As for the other two, am I right in believing that a general consensus
> has been reached?
>
> 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
-~----------~----~----~----~------~----~------~--~---
