There's no doubt that the worm making its rounds on Twitter is a nuisance and a huge problem for all. The fact of the matter is, somebody has collected your usernames and passwords, and many of your accounts are now Zombies, spamming each friend on your friends list through direct message, turning more unsuspecting accounts into zombies, and spreading like wildfire. Louis has talked about the worm which has surfaced on Twitter, and the urgency of the situation and potential implications for OAuth and security for Microblogging.I suggested plain text passwords could be to blame - after all, any application out there that collects your usernames and passwords could theoretically use those passwords to start such a worm, in order to gain access to people with similar bank account passwords and more. That would be the fastest way over, say, a single user trying to amass friends to dm. We're already seeing several of those compromised accounts sending iphone-related spam, so it would appear the worm developers could now be monetizing this, through your friends. At the same time, I keep seeing others criticizing the possibility that OAuth could have prevented this. I'd like to share my thoughts why.
Disclaimer
First of all, let me preface this with the fact that I am not a security expert. I have been developing software since I was 10 (I am now 31), and have plenty of real-world experience writing secure software. I've worked in health organizations requiring software to respect privacy around your health data, with e-commerce protecting your money, and I've written APIs. I understand what it takes to keep software safe. I also run my own business in which I also have to protect my users' data. I also understand that nothing's perfect. While security has not been my sole focus, I hope I can at least make some sense of the matter.
First Things First - This is an App
Let's set things straight here. Now, I could be wrong, but all evidence seems to suggest that this "worm" is actually an application, or possibly multiple applications, running on multiple servers around the world (the IP range also suggests that the same developers have targeted YouTube and Bebo in the past). After all, the only other way to log in on behalf of users and DM others would be to screen-scrape Twitter, simulating a user actually logging in via the Twitter.com interface. This is possible, but I would imagine we would see Twitter very quickly implementing some form of Captcha to slow it down. We haven't seen this yet so the most logical conclusion is that someone has written an App somewhere, which is taking advantage of the fact that you can login via plain text usernames and passwords. The same application is taking those usernames and passwords, and programmatically logging in on behalf of each compromised user and direct messaging their friends to collect more usernames and passwords.
Currently, the Twitter API makes it completely possible for anyone with your username and password to log in on your behalf, programmatically. Essentially, Twitter has given developers the key, and all keys open up the same lock. The only way to shut this down would be to kill the lock, which would shut off all developers. This is why the topic of OAuth continues to be brought up - to start off, OAuth forces any developer to use a protected key or token in order to log in on behalf of the user. The developer never has the user's username or password. The user himself keeps their own keys to Twitter without having to give a copy of those keys to developers.
It's not that simple though.
Why They're Saying OAuth Wouldn't Have Fixed the Problem
Assuming Twitter had implemented OAuth, let's assume no developer has your username or password and your information now feels secure. There is still nothing stopping those users from using those tokens to log in on your behalf. Essentially, while the developer couldn't screen scrape your data to log you in through Twitter with such a key, they could still use the API, just as these current Phishers are probably doing, to continue to send DMs and messages on your behalf. An OAuth token is just like another username and password essentially, intended just for API use.
The other criticism they're giving OAuth is that it still doesn't stop the Phishing. When the end-user authenticates through an OAuth-enabled website, they are taken back to a page on the originating site that, if they aren't logged in, asks them to log in, and that site in turn returns them back to the third party site with an OAuth token that can be used for access. Nice and simple, right? Well, the problem (which I've only seen theorized, but it is definitely possible) is that any third-party developer could create an app that redirects the user back to a page that just looks like the originating site (like Twitter.com, for instance), and pretends the user isn't logged in. The site could then collect the username and passwords of unsuspecting users, just as the current phishing scheme is doing now. The potential is still there to collect usernames and passwords, just as before.
The Advantage People Keep Forgetting
Let's ignore the last paragraph and just focus on the one before it. Even though an application can easily login on behalf of the user via the API, with OAuth, a site like Twitter now has full control over each and every application that runs on the API. OAuth has controls which allow API providers like Twitter to cut off any application using the API. So, assuming Twitter sets up some sort of manual approval process similar to Facebook's (I suggested this to Ev and Biz in the interview I attended with Scoble last year (end of the article), and they said they were working on this) to weed out the sketchy applications, it becomes much easier to just cut off the offending application. They now have record of the exact application sending these DMs, and can cut it off immediately. Currently, they're stuck chasing IP addresses, and trying to block various IP ranges, which are tough to block and easy to switch.
Back to the Problem
So, let's assume Twitter had implemented OAuth. We now have two possible scenarios: Scenario 1, said Phisher signs up to have an app on the API (or buys an app like Twply), and sends out DMs on behalf of users. (Note that the Phisher couldn't start as an individual and collect usernames and passwords in the manner this Phisher did in the current scenario because they couldn't send plain-text usernames and passwords via the API) The Phisher gets users' friends to login via OAuth, he collects the tokens to send out DMs on behalf of other users. Twitter's in-house alarms go off of such activity. Twitter shuts down said Phisher in a matter of minutes, and only a few people even see the worm.
Scenario 2 is a little more difficult, but less motivational for a Phisher on a site like Twitter. In this scenario, a Phisher creates a fake 3rd party app, accumulates a lot of followers somehow, and gets users to somehow think they are going to Twitter to login, and they collect the users plain-text usernames and passwords. The said Phisher can't do anything through the API, because it doesn't allow plain-text usernames and passwords. All they can do with it is screen-scrape Twitter, login on behalf of the user, and go about it that way. They also have to accumulate a decent sized following.
First, let's face it, there's not a ton of information that's not already public a Phisher can gather on such a site as Twitter, other than their username and password, which could also be used on other sites like banking sites. I really think most of these Phishers are more interested in spamming you, trying to make a quick buck off the unsuspecting sending spam to their friends (like the iPhone example above) - selling the data to spammers I'm certain is big bucks (at least $1,200, according to the sale of Twtply). Second, Twitter could easily implement a captcha system in such a case, and by that means they could at least slow down the Phisher or spammer. At that point, if the Phisher or Spammer is still diligent enough to get through, they have a much more controlled system, and they can then play the IP blocking game. Let's face it though - this isn't a banking site, usernames and passwords only go for a meager $1,200 from what we know, so most spammers ought to give up at that point. It's much less of a problem, and much easier of a problem to deal with than what Twitter is seeing now.
The Purpose of Security is to Make it Harder
As I said earlier, no security plan is a perfect plan, but the harder it is for a perpetrator to get through a system, the more secure that system is. Currently, there is no barrier between Twitter and those than can potentially misuse your usernames and passwords, other than you. As I said earlier, Twitter has only one lock for each user, and each developer you share your information with has the same key to that lock as you do.
However, despite the continued risk for phishing OAuth poses, as Lachlan Hardy suggests at the end of his piece here, it is still a step in the right direction, and I think would have prevented this particular worm. OAuth would have given Twitter the capability to revoke the keys of the offending phishers, enabling them to shut the worm down when it happened. After all, this isn't just a worm, it's an app, using the API, like any other developer, but in this case to spread malicious websites. I want to suggest that Twitter stop skirting around this issue, stop pretending OAuth wouldn't have solved the problem, and just implement something, quick.
Read more by Jesse Stay at Stay N' Alive.