On Thu, Apr 23, 2009 at 3:00 PM, Zachary Voase <[email protected]>wrote:
> > 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 > 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 > uncertainty, which is what any protocol revisions or provider > recommendations should tackle. Not sure we're on the same page here. The PIN (or callback nonce, callback token, or whatever you want to call it) would be generated by the provider, and the consumer would learn the PIN via a querystring param on the callback URL (for web apps) or via manual entry by the user (for desktop apps). The only way an attacker could exploit this scheme would be to convince the victim to enter the PIN on an unknown site, and we have other mechanisms to prevent this from happening (browser chrome, certificates, etc). Mike --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
