The OAuth/Twitter kerfuffle.

As a lot of people now know, Twitter’s been hit by the result of a few dodgy design decisions from the past (we’ve all made them at some point) and this has prompted a large call from web developers for Twitter to support OAuth, an authentication protocol that supposedly provides a bit more security than people going around and giving out their username and password to any old service.

I’m going to summarize the pros and cons of using OAuth with Twitter, and then I’ll follow up with a couple of suggestions I have for fixing the issues.

So, what’s this all about? Well, basically there is a service called Twply which asks for your Twitter username and password, and e-mails you every time you get a reply from someone. On signup, it gives the option to ‘support’ Twply, basically saying something along the lines of: “can we post a tweet from your account that advertises our service?” Needless to say, many people respond with “No.” Of course, Twply seems not to give two shits about what you want it to do, so it goes ahead and tweets the advertisement anyway. Lovely. So now, a bunch of Twitter users want to stop Twply from accessing their account; trouble is, they can’t without changing their password. Ug.

Obviously, users of Twitter are enraged at the service for a breach of trust. But it turns out that this was just an incident waiting to happen. You see, the Twitter API is structured so that any application that needs access to it, has to use your username and password. Which means you are giving your username and password to other people, and blindly trusting them not to do something stupid or evil. Clearly someone, at some point, was going to abuse this trust. Twply has done so.

Then, all eyes turned to OAuth. OAuth is a protocol, designed by a few smart people, which allows you to give a third-party app (a ‘consumer’) permission to access a service (a ‘service provider’, i.e. Twitter) on your behalf. Now, basically, you are giving access to the consumer, which isn’t that different from giving them your username and password; where OAuth differs is that you can control access, only allowing the service to do certain things, and you can also revoke access without having to change your password. So you can see that, if OAuth were implemented on Twitter, people wouldn’t have to change their password, they could just go into some management console and revoke access. In this respect, OAuth is good. Also, people could have given Twply read-only access, meaning it could access their replies (in order to e-mail them) but not be able to send tweets from their account.

OK, so OAuth seems to be pretty cool - though we can’t forget the cost of adoption, and the fact that it will have to be phased in over a relatively large time scale. But some people have expressed concerns over a vulnerability in the protocol. OAuth requires that the user log in with the service provider before it will grant access to an application. It is the responsibility of the consumer to redirect the user to Twitter to log in; this means that a fake consumer could potentially (maliciously) redirect a user to some phishing site and steal their password. So we need some kind of identity verification to make sure that you are, indeed, entering your details into Twitter, rather than a phishing website. This can be done in a couple of ways; firstly, Twitter should by default use HTTPS, and thus Twitter could be verified as the service provider. Secondly, users would have to be educated to check the authenticity of websites before entering sensitive data into them. Firefox (and maybe some other browsers - I don’t know) already checks against a blacklist (maintained by Google) and warns users when they are entering a potential phishing site. The phishing problem is one which will bug Twitter whether they’re using OAuth or not - it’s relatively easy to set up a clone of Twitter’s homepage and start spoofing users into handing over their credentials.

So, to put it bluntly, OAuth isn’t the silver bullet that will kill phishing once and for all, but it’s certainly a step in the right direction. You shouldn’t make your users think it’s OK to just go around giving their usernames and passwords out to everyone who asks, but likewise, it’s stupid of users to do that as well. I’ll be the first one to admit that I’ve been stupid with my password; about a month ago, I changed my password to a very secure one, and removed myself from as many third-party services as possible. I won’t be signing up for any new services until OAuth is implemented and also until the first hole is found (because there probably will be quite a few holes to begin with).