|
|
|||||
Twitter kills the password anti-pattern, but at what cost?Assertion and delegation of identity can now be easy or safe. But we need both.Last week Twitter ended basic name/password authentication to its API. This was announced well in advance. Still, like many procrastinators, I found myself scrambling to learn what is now the only available way to authenticate to the Twitter API: OAuth. Some people can visualize how these kinds of protocols work by reading specs and flow diagrams, but I'm not one of them. For me it doesn't really sink in until I create a working implementation. So I embraced the opportunity to solidify what had been just a theoretical understanding of the OAuth protocol. I've also long embraced the principle that motivates OAuth. You should never have to give your name/password credentials to a third-party application or service so that it can impersonate you. This so-called password anti-pattern is profoundly wrong. When legitimate applications and services ask for permission to impersonate us, we learn that it's OK to do things that way. It isn't. Malicious actors can and do exploit our willingness to give up our credentials. How can I authorize a third party to access my data on a service like Twitter, and use its capabilities on my behalf, without giving it my credentials? OAuth is a clever solution to this hard problem. A third party that would otherwise need my credentials to do something can interrupt the transaction, send me to Twitter where I authorize it to act on my behalf, save a token that represents that authorization, and then resume the transaction. In my case, though, that's a solution to a problem that I didn't have. OAuth is a three-party protocol. It typically involves a user, an application or service that the user authenticates to directly, and a third-party application or service to which the user delegates agency. The elmcity/Twitter scenario, though, is really just a two-party game. As I discussed in "The power of informal contracts," the elmcity service uses Twitter as a channel for authenticated messages sent from event curators to the service. Here's how it works. If you're the curator of an elmcity hub, you can associate your hub with a Twitter account. The elmcity service, which exists in Twitterspace as @elmcity_azure, will follow your Twitter account. That enables you to send direct messages to @elmcity_azure. The service reads and reacts to messages sent through this trusted channel. In this scenario there is no third party. As far as Twitter and the curators are concerned, the elmcity service is just another Twitter user. Of course it isn't a human sitting in front of a browser, but rather a service running in the cloud. So it has to use the Twitter API to follow curators, and to read the direct messages they send to it. When I had the idea to do this, the implementation came quickly and easily. Why? Because the activation threshold was low. Until recently, it was dead simple to access the Twitter API, using HTTP basic authentication, in order to try out interesting ideas. Earlier this year, for example, I wondered what it would be like to visualize the names of your Twitter lists as a tag cloud. I sketched a solution using a simple web page that used JavaScript to call the Twitter API and render results. The page asked for your Twitter name and password, but I explained that things weren't as they might have seemed:
When you try that page now, the Twitter API responds: {"errors":[{"code":53,"message":"Basic authentication is not supported" }] } Are there JavaScript libraries that would enable me to recreate this app using OAuth? Yes. Will I bother to acquire, evaluate, learn, configure, and use them? No way, life's too short. And anyway there's no great loss here, it was just a sketch of an idea. What is lost, though, is the possibility to sketch a lot of other ideas. The unexpected way in which the elmcity service uses Twitter is, I argue, an interesting and useful model. Having concocted it, I went to a fair bit of trouble last week to move it from basic authentication to OAuth. In a companion article at O'Reilly Answers I share what I learned about libraries, tools, and techniques that can help developers work with OAuth. It's a complicated dance of cryptography, redirection, and callbacks. So complicated, in fact, that if I'd had my idea today instead of six months ago I probably wouldn't have bothered to jump through all the hoops. According to Eran Hammer-Lahav, who is the editor of OAuth 1.0 and also an editor of OAuth 2.0, the 2.0 protocol will make it possible again to sketch ideas using simple tools:
Good! But OAuth 1.0 is only now gathering momentum. OAuth 2.0, which isn't backward-compatible, will require its own long runway. I'm glad to see Twitter driving a stake into the heart of the password anti-pattern. But the Twitter ecosystem wouldn't exist if it hadn't been possible to sketch ideas, and to explore the unanticipated uses that can emerge from the soup of active ingredients that the web has become. We must not teach people to give up their credentials and expose themselves to attack. We must, however, teach them to savor that soup of ingredients, to expect novel concoctions to arise from it, and where possible to create their own. These innovations require us to assert and delegate our identities. Today that can be easy or it can be safe. Until it can be both easy and safe, we'll be forced to make painful trade-offs. Related:
|
|||||
© 2012, O'Reilly Media, Inc. (707) 827-7019(800) 889-8969 All trademarks and registered trademarks appearing on oreilly.com are the property of their respective owners. |
|||||
Comments: 15
Rabble [10 September 2010 10:56 AM]
What you are looking for is called Two Legged OAuth. You're authorizing between the client app and the server, the user itself is not so important.
Now with twitter, you can't do things to the site, without doing them as a user. So you've got three legged oauth, you just need to know that you're controlling both the client and the user, so it's pretty easy.
Jon Udell [10 September 2010 11:24 AM]
The two-legged variant doesn't get much play, and I hadn't known about it, thanks for pointing that out! As you note, though, this ends up being a three-legged scenario in which I control two of the parties. It's doable, and I am doing it, but easy it was not :-)
Keith Grennan [10 September 2010 11:56 AM]
Though OAuth 1.0 is complex compared to basic auth, it reflects the requirements of a more complex world. These days developers need to understand delegation, assertion, tokens, etc in order to play in the ecosystem.
That being said there is perhaps a lack of good tools for getting started with OAuth 1.0. The best I've seen so far is Google's OAuth Playground, which walks you through each step of the process and shows all the messages being passed back and forth.
http://googlecodesamples.com/oauth_playground/
As a maintainer of an OAuth library (Perl) the most common question I get is 'my signature failed and I don't know why'. So perhaps the crypto element is bulk of the higher activation threshold. Another roadblock is that various service providers add custom OAuth extensions that are not supported in all the libraries, and this lag causes yet more developer pain. Hopefully OAuth 2.0 addresses these issues, and helps converge the service providers' extensions into a more complete core spec.
Dr. Yalik [10 September 2010 12:03 PM]
I am not very technical but was always a bit suspicious of authorizing a third party to access my data on Twitter, and other sites for that matter, I am only now realizing that I was right :-)
There must be so many non-techies out there though just accepting everything as it pops up on their screen. This is very worrying.
Eric Falconer [10 September 2010 01:43 PM]
Arstechnica has a great write-up on a far more troubling issue with Twitter's OAuth implementation.
http://arstechnica.com/security/guides/2010/09/twitter-a-case-study-on-how-to-do-oauth-wrong.ars
The issue is that twitter forces desktop applications to include their secret key, which is a huge no no - a problem that facebook / google have solutions for (outlined briefly in the article).
It is fairly trivial for someone to extract this secret key with some debugging tools (several people have already demonstrated finding and extracting the official twitter key) and once a key is found to be compromised, twitter has said they will block access to that application.
So someone downloads your app, extracts the key, posts it to a blog, and suddenly your app is blocked from the API. In the case of an iPhone app this could potentially kill it since it would take a long time to get a new version re-certified that has a new key, and many people will have simply moved on.
Zoo Jing [10 September 2010 01:46 PM]
OK this makes a lot of sense dude.
www.anon-vpn.us.tc
cori [10 September 2010 02:02 PM]
Not having an app in the twitter coral reef I don't have much of a stake in this matter yet, but I do have some ideas kicking around that I'm interested in sketching out.
So I'm curious; is the effort required to build up to a working knowledge of the OAuth framework in any given space or language transferable? I mean now that you've done it for elmcity, does that bring the OAuth Dance complexity back down to the level where sketching ideas become feasible again - just a one-time learning curve?
bob [11 September 2010 09:07 AM]
At the cost of free MINUS the exact cost of your identity being stolen.
Till | iTanum [13 September 2010 10:31 AM]
Some of my wordpress-blogs, i wondered why i should update the twitter authentication. Some wordpress-twitter-plugins are not available since changing to oAuth. For non-techies it isn't possible to understand what to do.
Jeff S. [13 September 2010 10:54 AM]
This concept of not divulging information to third parties directly - it's something I first thought about, around 8 or 10 years ago.
I wasn't thinking about it in terms of user login, but a different form of user authentication - online commerce transactions. It always bugs me having to give out credit card info to make purchases online. One 'solution' to that problem is using something like Paypal - the problem is, paypal is yet another third-party being added to the transaction/trust chain, which I find undesirable - I'd rather being dealing just with the merchant and Visa/Mastercard/Amex/Discover (whichever network my card is part of); also, not every site supports paypal; thirdly, I don't like the thought of paypal being a monopoly on such a service online, with no one being able to compete with them, but for such a scheme to work, it's not desireable to have 1/2 dozen different systems which vendors have to support.
Anyhow, point is, it occured to me in the early 2000's that a *better* system for online payment would have users being temporarily sent from a merchant's online store over to the Visa/Mastercard website, where the user would authenticate, review the proposed transaction (e.g. make sure the dollar amounts the vendor submitted to the CC company matched what they agreed to purchase), then authorized (or decline) that one transaction, then the CC company site would redirect users back to the merchant (and as part of that redirection, would include a one-time-use transaction token which that merchant would use when submitting a request for payment from the CC company.
Initially teaching people to use such a system securely would be a bit of a burden, but the security of never giving *re-usable* credit card account information to online merchants seems like it would be very desirable, no?
Adam Trachtenberg [13 September 2010 11:24 AM]
I joined eBay right after we had our own version of this type of migration. In 2004.
One of the lessons we learned is you need to have a very simple web tool that allows a developer to have the site generate authentication tokens for themselves. Because there are a lot of people who write application for just one single customer, who is almost always them, or a member of their company. So, why bother making them implement the general sign up flow for the specific use case?
Of course, with OAuth, you still need to wrangle with the signature base string (which eBay avoided by using SSL for all communications). Which causes even more trouble than the rest combined, unfortunately.
NerdUno [13 September 2010 05:13 PM]
I was just as frustrated by Twitter's OAuth as you were. It really makes no sense for those that use Twitter in a private network for private purposes. But so be it. After lots of wrestling, it turns out it's not as clever as they thought. Think of it this way. In lieu of divulging your Twitter username and password, you now provide username2, password2, username3, and password3. And these four entities can be different for each application you wish to activate. Problem was that Twitter has made it next to impossible to get all 4 of these credentials, and they sure as hell haven't documented it well.
In the end, we wrote a simple web page on the Internet that will let anyone decipher the 4 magic codes. You'll just have to trust us not to steal your codes which long-time readers of Nerd Vittles never had a problem with. For details, visit this article: http://nerdvittles.com/?p=698. Then read the section on TweedleD Setup. You can use it for any Twitter application, not just ours. Good luck!
Jon Udell [14 September 2010 06:13 AM]
@Jeff S. I love the concept of one-time credit card numbers, it's been tried here and there, I always hoped it would catch on, but so far not. One problem was that it was web-only, and really needed to also work at the bricks-and-mortar point of sale. As smartphones proliferate that may finally become possible.
Jon Udell [14 September 2010 06:18 AM]
@Adam "Of course, with OAuth, you still need to wrangle with the signature base string (which eBay avoided by using SSL for all communications). Which causes even more trouble than the rest combined, unfortunately."
It sure does. One thing that helps is for the service to report the signature base string when an attempt fails. But requiring one at all is a huge obstacle.
jrep [14 September 2010 09:45 AM]
The biggest danger with OAuth is that it sends developers down these rabbit holes of implementation details, alternative patterns, and standards progressions, entirely missing the more fundamental problem that the end user is still giving away incredibly valuable information, very nearly as dangerous as the credentials themselves.
To the end user, all OAuth dialogs look the same. While OAuth provides means for the authorizing app to restrict the rights granted to the client app, there's still no adequate way to enable end users to judge the effects of their decisions. All too compellingly, they consider "do I want this one thing I'm trying to do right now" (a question whose answer is always "yes"), and neglect, or are denied, any consideration of "do I want all the other things this client app might do with this permission?" The core problem is granting no more rights than the end user intends, and given the complexities of the possibilities on the one hand, and the near guarantee that the user has something other than "rights management" on their mind at the crucial click, this is a problem that OAuth does little to solve.