Would You Like Some Quechup with Your Phish & Chips?

Public comments about OAuth are a great opportunity to explain the thinking and goals behind the protocol. Rob Sayre asks about the protocol use of redirection in order to get the user to grant access:

“Maybe I’m missing something, but doesn’t this train users to enter their credentials into web pages they’ve been redirected to?”

First, you are correct. Redirection carries with it some risk of training users to follow a pattern of coming to a login screen without explicitly entering a URL in the browser address box. The basic idea behind phishing is getting the user to a page they think is one thing but is really something else. A link in an email message made to look like your bank is actually a fake page asking you to enter your username and password. When you fall for it, it usually redirects you back to the real bank to enter it again (making you think you just mistyped).

OAuth’s primary goal is to prevent the need to share your password with legitimate applications you really want to use. Many sites today do not provide an API because they don’t want their users’ passwords shared with anyone. But as Twitter proves, providing an API can be what puts you way ahead of the pack, and providing an API is becoming more and more essential to running an internet business. With that in mind, having a consistent way to delegate access is critical.

The best solution to phishing attacks is to never enter your password into any web page you did not manually enter (or followed your own bookmark to). OAuth cannot help careless users, and phishing is all about not paying attention to what you do. There has been some interesting discussion about phishing on the OAuth group and the bottom line is, it is far beyond the scope of the protocol. Guy Huntington makes some very good points on the subject.

In order for the OAuth to work, the Consumer (website or application) has to “ask the user to grant access” in order to get the User’s Protected Resources. OAuth does not say how the Service Provider is going to do that. Some OpenID vendors do not allow you to sign-in from a redirection, instead they ask you to open a new browser, go to the login screen and sign-in manually. They only allow you to grant access via redirection once you are already signed in. OAuth Service Providers can implement the same logic which will help break bad habits. They can also use OpenID to reduce the amount of usernames and password the user has to deal with.

An important point to keep in mind that one of OAuth’s design goals has been to keep it as simple as possible and easy to implement. If you make it too hard, those 3rd party application developers will just ask for your users’ passwords and screen scrap their data as they do today. Google is an example of a company that consciously made their AuthSub protocol looser to make it more appealing for developers to adopt (and stop screen scraping).

Google AuthSub is perfectly safe when used over HTTPS but not so much when used over HTTP. Google’s solution is to display a big red warning when you are about to give access to another application over a non-secure channel. Everyone has to compromise somewhere. OAuth leaves it up to the Service Provider to decide just how secure their resources should be, while establishing a framework developers can use across sites.

At the end, let’s not forget that infamous Quechup didn’t use phishing to scam users in order to gain access to their Google address book and spam all their friends. They just nicely asked for your password and then abused it. They could have as easily placed a few charges to your Google Checkout account while at it and users are lucky they didn’t.

A well implemented OAuth Service Provider can give users greater control over what they are exposing and for how long. While OAuth would not have stopped Quechup from using your address book in ways you did not allow, it would have made it trivial for Google to simply block Quechup Consumer Key as soon as reports of abuse appeared, and prevent them from more API abuse.

So my counter quote is: “OAuth doesn’t train users to enable phishing – it trains them NOT to share their usernames and passwords with anyone. And they will no longer have to.

As for getting users to stop spreading their passwords around and getting sites to implement OAuth, well, for that I only have one solution – Karl Rove. And I promise to explain it very soon.

One thought on “Would You Like Some Quechup with Your Phish & Chips?

Comments are closed.