On Fri, Apr 24, 2009 at 3:19 PM, Seth Fitzsimmons <[email protected]> wrote: > I'm a fan of this proposal. At its heart, the attack being discussed > is social engineering; changing the flow (adding signing, limiting the > variety of callback urls, etc.) is a way to mitigate (and mostly > prevent) it, but when it comes down to it, it's a matter of trust.
I agree that the problem is exquisitely a "social engineering" one and it would be better to solve the A-B exchange but... > I still believe that the approach is sound; instead of an identity, > the consumer could generate a phrase (since this has a much higher > likelihood of being unique and recognizable), display it to the user, anything that the consumer shows in step A would be known to the attacker so could be possibly used in the social part of the attack, maybe this phrase should be generated beforehand and be specific (or unique) to the user at the given consumer, and the users might be then trained to check it on the authorization page and do this: > they *should* see the same phrase. If they don't, they click the equivalent > of the "THAT'S NOT > ME" button and the authorization fails. ... > MovableType plugins sharing a single consumer key/secret pair, > identifying as "MT Plugin for X", installed on servers across the web. > Think of them as desktop apps w/ the ability to register protocol > handlers (but where the URIs must vary). uh this is an interesting use case for the variable callback Luca --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
