Everyone is using terms like "mitigate" rather then "fix", which a clue there is probably a flaw in design that isn't accounting for the social engineering aspect.
Maybe something that could confuse users to give their user credentials to a third party and not the real OAuth provider when they think they are authorizing the consuming app. The other idea is a possible man in the middle attack. I made a proof of concept for something like that but it was to many steps to setup to think anyone could ever deploy it. Interested to hear what it is. Zac Bowling http://twitter.com/zbowling On Wed, Apr 22, 2009 at 1:27 PM, Alex Payne <[email protected]> wrote: > > http://blog.twitter.com/2009/04/whats-deal-with-oauth.html > > In short: there's a security issue with OAuth, and the major OAuth > providers are working together to patch the vulnerability before > information about the issue is publicly released. That information > will be available at http://oauth.net/ at midnight, PST. > > In cooperation with this consortium of other OAuth providers > (including Yahoo!, Google, Netflix, etc.), we agreed not to disclose > the nature of the vulnerability, nor even that a vulnerability > existed, until all members of the group agreed to do so. I apologize > for what must have seemed unnecessarily tight-lipped communication > around this issue, but please understand that we and the other > companies involved are trying to mitigate the impact of this > vulnerability as much as possible. > > Please also note that our OAuth support is in beta, albeit public > beta. We have not suggested to developers that they rely solely on > OAuth until our support of the standard leaves beta. I know that some > companies practice a policy of "perpetual beta", but at Twitter, we do > not. For us, "beta" really means "still in testing, not suitable for > production use". > > Thanks for your patience and understanding. > > -- > Alex Payne - API Lead, Twitter, Inc. > http://twitter.com/al3x >
