Twitter and the Password Anti-Pattern

I’ve written about the password anti-pattern before, and have, with regards to Twitter, advocated for the adoption of some form of delegated authentication solution for some while.

It’s not as if Twitter or lead developer Alex Payne aren’t aware of the need for such a solution (in fact, it’s not only been publicly recognized (and is Issue #2 in their API issue queue), but the solution will be available as part of a “beta” program shortly). The problem is that it’s taken so long for Twitter’s “password anti-pattern” problem to get the proper attention that it deserves (Twitter acknowledged that they were moving to OAuth last August) that unsuspecting Twitter users have now exposed themselves (i.e. Twitter credentials) to the kind of threat we knew was there all along.

This isn’t the first time either, and it probably won’t be the last, at least until Twitter changes the way third party services access user accounts.

Rather than focus on Twply (which others have done, and whose evidence still lingers), I thought I’d talk about why this is an important problem, what solutions are available, why Twitter hasn’t adopted them and then look at what should happen here.

Why the password anti-pattern matters

I can’t link directly to it, but comment #8 on Fred Oliveira’s post captures one clear reason why the password anti-pattern increasingly matters more:

Regardless of the perceived value of the service, when it comes to reputation online, little else matters than one’s accumulated social and data capital. Some people store their data capital (essentially original content coupled with residue from their social capital) with LinkedIn; others, Facebook or MySpace. Still others use their own blogs or rely on a medly of services like Twitter, FriendFeed, or Flickr.

To some degree, experimentation with third party services can elevate one’s status, drive commerce, or provide a recommendation filter for friends. So handing over the keys to the vault that stores your data capital should be a big deal.

The more frequently we do this, the more routine it becomes, the more we become desensitized to the inherent risks in this behavior. And so we take it for granted that we must cough up a username and password in order to try out that new shiny service, given the countless times previously where nothing bad happened. And then you get Twply. Or Quechup.

Now, phishing works in a similar way, but is distinctive in an important respect:

In the case of phishing, it’s kind of like a faux valet that stands outside a well-regarded restaurant waiting for unsuspecting victims to hand over the keys to their Benz (where that restaurant is your email account). Once a phisher gets a nibble, they position themselves as a known authority (i.e. your bank), preying on the naivete and disorientation of their victim. No where better is there than the web for such schemes, where the true value of account credentials are abstract and technical.

The difference between run-of-the-mill phishing and password anti-pattern cases is intent. Most third parties implement the anti-pattern out of necessity, in order to provide an enhanced service. The vast majority don’t do it to be malicious or because they intend to abuse their customers — quite the contrary! However, by accepting and storing customer credentials, these third parties are putting themselves in a potentially untenable situation: servers get hacked, data leaks and sometimes companies — along with their assets — are sold off with untold consequences for the integrity — or safety — of the original customer data.

Given the ends (providing cross-site functionality (importing address books, posting to blogs or Twitter, etc)), you could argue that the means are incidental or justified. But we can — and have an obligation to — do better.

Solutions for the password anti-pattern

Given the prevalence of this problem, several solutions have emerged, most notably OAuth.

OAuth is actually an extraction of a number of protocols that came before. In the place of a username and password, it substitutes a consumer key (like a username for an application) and a token, and adds a cryptographic signature to make sure that no one tampers with the “request envelope” while in transit.

Interestingly, OAuth emerged from a shortcoming with OpenID. Since OpenID authentication works without passwords, we needed a way for OpenID to be used with APIs and in desktop applications. Therefore, we needed a way to delegate authentication back to an original source, and then receive authorization to act on behalf of the user, all without ever needing their user credentials. Of course this problem wasn’t unique to OpenID, and so we developed it to be agnostic about how authentication is performed (that is, with or without OpenID).

Since its release just over a year ago, OAuth has replaced both Yahoo and Google’s custom delegated authentication protocols, and has become a central component of OpenSocial. More recently, Eran Hammer, the specification’s editor and lead author, brought OAuth to the IETF in order to advance the community-driven protocol to the next level of internet infrastructure. But it’s not the only solution to this problem.

FriendFeed implements what they call a Remote Key in place of a user’s password:

What’s a remote key?

A remote key is a kind of password that you can give to third-party applications and websites to let them interact with FriendFeed on your behalf. There are limits to what can be done using a remote key, which means it’s a lot safer than giving a site your FriendFeed password.

This idea was suggested to Twitter in November.

While there are benefits to this model — especially in terms of simplicity — it requires a user to remember two secrets: their password and their remote key. It also means that all third-party applications act at the same level of authority, since services can’t distinguish one application from another. For a service like FriendFeed, where most of the interactions seem to happen on-site, this model makes sense. For a service like Twitter, whose primary traffic comes from external sites and applications, it does not.

And then there’s the “security through obscurity” solution that provides access to data with single or limited use URLs that are usually so long and cryptic as to be virtually unguessable. This is the solution that Basecamp offers its OpenID users and that Flickr uses for its guest pass service.

Twitter and OAuth

Anything besides the standard username and password combo will arguably add complexity and confusion to the user experience of web apps and mashups (both for users and developers). Alex Payne made this point loud and clear:

Still, sooner than later, something is going to need to be done. And Twply is only the tip of the iceberg. As people continue to accrue social and data capital, we’re going to need to offer them better options for securing their accounts while providing them flexible and usable access. The sooner we start training people on the new model, the better off we’ll all be.

But Alex has additional gripes about OAuth:

The downside is that OAuth suffers from many of the frustrating user experience issues and phishing scenarios that OpenID does. The workflow of opening an application, being bounced to your browser, having to login to twitter.com, approving the application, and then bouncing back is going to be lost on many novice users, or used as a means to phish them. Hopefully in time users will be educated, particularly as OAuth becomes the standard way to do API authentication.

Another downside is that OAuth is a hassle for developers. BasicAuth couldn’t be simpler (heck, it’s got “basic” in the name). OAuth requires a new set of tools. Those tools are currently semi-mature, but again, with time I’m confident they’ll improve. In the meantime, OAuth will greatly increase the barrier to entry for the Twitter API, something I’m not thrilled about.

These are actually very good points.

At the same time, there’s a balance to be found between accepting the status quo (thereby promoting it) versus creating the solution. Alex has repeatedly referred to the work of the Twitter User Experience team as slowing down their adoption of OAuth, but it seems to me that there’s been an open opportunity to engage with the OAuth and OpenID communities to address these issues, especially as they are at the core of why Google has yet to become an OpenID relying party. These problems are not unique to Twitter and are issues that the entire community needs to address. As much as I’m a pain in the ass about OAuth support in Twitter, I am also willing to jump in and help develop solutions — but thus far, Twitter has been absent from the channels where solutions are being generated.

Everyone’s got their priorities and Twitter has come a long way in the past several months in terms of performance and stability. But in 2009, I want to defeat the password anti-pattern once and for all! Starting with Twitter would be a significant strategic achievement and I know that Twitter is game, it’s just matter of getting it done and making it happen.

So, Alex, where do we begin? What can we do to help?