Peter Keane wrote: > On Mon, Apr 27, 2009 at 10:50 AM, Eve Maler <eve.ma...@sun.com> wrote: > >> Peter, thanks for putting the PIN idea in context for me. This is >> perhaps a dumb question, but since testing equivalence of the *user* >> (a bag of protoplasm) is sort of a last-mile problem anyway, and since >> -- if I'm understanding the long Security Advisory discussion thread >> correctly -- even PINs have social engineering risks, aren't we really >> just looking for ever-better ways to do "weak" equivalence rather than >> testing true equivalence? >> > > Hi Eve- > > That's definitely something to think about, except that we can thus > move the exploit completely into the social realm (where things like > phishing live). I'd say from an authentication point of view, you are > actually storing "state" on that bag or protoplasm :). OAuth > leverages a bunch of existing standards/practices and giving user > control of their identitiy is one of them. (I.e., lots of > authentication schemes, even that used my my bank does the same). > > The specific social engineering risk mentioned in the Security > Advisory thread centered on my original proposal that the user enter a > PIN at A that they type again at B. The concern was that the attacker > could convince the victim to type that in (since the attacker would > have created it). > > My latest thinking entails the SP offering the PIN (I'm calling it a > "valet key") after successful user authentication, which the user > would be required to type in from the consumer side before getting the > access token. (this is B-C interaction). That eliminates the > possibility of the attacker coaxing the victim to enter it. > >
I can see the benefits of the B-C interaction, but if it is initiated on the SP side, I would prefer that it be possible the user can supply it in some manner during authentication. I have cases where I am not present during a transaction, which made me cringe when someone suggested images here, and a trusted app handles the interaction with consumer and SP - hence why the A-B scenario would be ideal, but I digress... If it were presented in a UI, then it would need to perform some screen scraping to get access to the key or try to convince an SP to create a separate authentication process for this scenario where it would then return the value upon successful authentication. Rob --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
