You can’t rely on IP addresses to ensure identity. I’m actually mostly likely to want to carry out this kind of attack against my coworkers who’re sitting behind the same IP as me in my office right now You can’t rely on sessions on the Consumer (ie: Twitten) side of things because Bob may never reach that page. As Eran said you can manipulate the callback URL as part of the attack to prevent Bob from ever seeing a genuine twitten.com page.

Until we come up with approaches to prevent this it’s not about knowing which applications are safe because none of them really are.

You guys have thought longer about this than I have but…

Alice’s session and Bob’s session should have some unique characteristics to them, would they not? Couldn’t some hashed value and an IP address be used to validate that the authorization URL to validate Alice is really for Alice? Bob can’t use it because we’ve locked the authorization URL just for Alice. Alice’s session has unique values in there that we are going to check for.

As I’m thinking about it, it seems you have to trust that Twitten is going to take these kinds of measures. What about other parties that don’t? Could there be a list of approved parties that do? Ultimately, you are right, it is all about trust.

I would use Twitten based on the fact that other people are using Twitten and have not reported problems. I would not be using Twitten just because it uses OAuth or some we-won’t-do-anything-shady-with-the-authorization-you-give-us certification. It’s their reputation. I don’t have the tools to peek under the hood to tell what they’re doing and how they’re doing it.

So we fall back to what are the social mechanisms that we have in place that render an aura of trust around a particular company or service? What are the protocols of accountability? What are the consequences should they breach that trust?

Hmm… it’s just as much about social practice as it is about the technology.

Rahim

One defense is for the Consumer to make sure that the session in the callback is the same as the session when the token was requested, but I think there may be some ways around that. Ultimately OAuth is better than what came before, but in itself not the solution to all of our phishing problems.

I suppose this too could be spoofed with an iframe of the just the Oauth button sized to hide the text, though then the URL wouldn’t be twitten and could be another signal.

There’s also the operation from the other side of the Oauth. After being fooled by Alic, I should be able to go to my account in Twitter and Remove the Twitten application that Alice has authorized as soon as I see that something up. Granted, she may have already done the damage.

At the end of the day, I think it boils down to just not trusting any link to an OAuth page that isn’t coming off of the site that one wants to authorize. I would hope that everyone learned the “don’t click OK on everything” lesson by now, but I know it isn’t so.

7. Twitten requests Twitter to exchange the unauthorized token for an access token (associated with Bob’s Twitter account) and stores it in Alice’s session

Also, note that the attacker needs to play with callback in most cases to make it work.