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?
22 thoughts on “Twitter and the Password Anti-Pattern”
[this is good]
“These are actually very good points.”
A bit more than that. The first point is the killer for OAuth. If developers are muddling their way through the specified redirections and token exchanges, then people are going to get lost on the flows. As for developers, an approach that will work on phones and settops not just desktop browsers will help. That way I won’t have to document what you call the password anti-pattern and what I see as the de facto practice of client logins:
Someone with slightly more time on their hands than I could implement a Twitter OAuth proxy (much like Simon Willison did with OpenID, idproxy.net and Yahoo logins). Yes, they’d have to keep hold of all the usernames and passwords for a while, but developers could choose to develop against it, and it would hopefully be only a small tweak to shift apps to use the “real” API when the time comes.
> 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.
I don’t think that’s what S-T-O means at all. All password systems and many crypto schemes would be S-T-O if that’s what the “obscurity” part was referring to.
But S-T-O is a different, important concept that people are still confused about, so we should get it right when we talk about it. Pretend it’s short for “security through algorithm obscurity”. E.g. “many proprietary voting machines today are relying on security through obscurity”. Long random URLs, on the other hand, become increasingly secure the more you learn about how they’re generated and used.
What about an Prize style competition to help encourage a solution to Alex’s “additional gripes” about n00bs and Oauth? I reluctantly acknowledge his points, but refuse to accept that there nothing that can be done.
Outside our geek sphere, the X Prize competitions for space travel and a 100 mpg car have successfully spurred innovation and gotten results.
In an odd bit of serendipity Mark Krynsky ( @krynsky )is the Web Producer for X Prize Foundation AND runs the Lifestream Blog( ??? ). I could hit him up and ask for his input on how to conduct an X Prize.
Is this a good approach?
I think this is a case where Twitter should (at least for a while) support *both* HTTP Basic Auth and OAuth. This way, developers could still “walk up and use” the API with Basic, and even build some simple apps with Basic, but developers that care could also use OAuth, and if/when an app starts to get some traction, users could/would demand that they move to OAuth, which at that point would be an easy move to justify. This is also how we do it with Portable Contacts–it technically supports both HTTP Basic and OAuth, with the assumption that big sites in general are not going to support Basic (either technically or by policy), but this helps eliminate the “watch out for that first step, it’s a doozy” challenge of developing with OAuth. 🙂
Chris, as you know from my comments on the Twitter dev list I’m more than annoyed by Twitter’s lack of response on this. Thanks for working to bring more attention to this. If I can do anything to help please let me know. As I said on the list, I don’t care what it is, but whatever the fastest solution they can release and have it out now is the solution they should implement
@Joseph, I agree that Twitter should support both their existing authentication mechanism and OAuth for quite awhile.
After adding OAuth support, they’ll need to be pretty proactive in getting client developers to switch their applications to use it. They’ll then ideally continue following up with developers who are still using passwords to better understand if there is a reason beyond time that they haven’t yet made the switch.
Completely turning off their password based API authentication doesn’t seem like a great idea since, as you said, they’ll want to keep their API dead simple for developers to get started with.
@joseph : The plan is to support Basic Auth and OAuth concurrently, for at least 6 months, if not more.
We can’t completely turn off the Basic Auth API without having a large impact to many APIs and clients.
What “Irony” in your tweet? Even if all remote sites took OAuth, this thing was designed to look like twitter, and you don’t use OAuth from Twitter to log into Twitter!
Sometimes I want to punch you in the face, Chris.
I don’t buy the “developers would have a lot of trouble understanding it” argument. Yes, it’s more involved than Simple Authentication but I was able to implement a web app client using the Flickr and Google authorization mechanisms in a few days, and that was using a new language and a new web framework in the bargain. Once you see how one works, it becomes a lot easier to understand the others as they all work on the same basic strategy. Also, there are open-source client libraries in many languages that simplify the developers job. Although quite frankly, I wrote the Google auth code making straight HTTP calls. I can’t imagine OAuth is that much more complicated.
I think the larger issue here is that Twitter has a moral obligation to at least try to provide whatever protection it can to its users’ identities. The argument of “if you don’t like it don’t use it” is simply cavalier. People are using this service for more than just talking about what they had for breakfast. Twitter has a responsibility to their users and they ought to step up and fulfill it.
The irony, Tom, is that Twitter titled their post “Don’t Share Your Secret Info!” and yet that’s the only way that you can use third-party apps, which Twitter clearly promotes. If Twitter says “don’t share your secret info” but don’t provide a way to still make use of third party apps, it’s ironic because we’ve been saying that all along.
I think it’s time for your mom to send you to your room. You need to study more.