Trust, Twitter and Passwords
After we launched TwitOrFit we noticed a rather surprising backlash within the Twitter community. Many users were unhappy with trusting a web-based service, such as TwitOrFit, with their Twitter credentials – and rightly so – giving out your password is one of the cardinal sins of the online society we live in.
However, many people don’t seem to realise that without both their Twitter username and password, there’s very little external services can do with Twitter. And this is the crux of the problem – Twitter’s API requires you to send the username and password of the user with every API call.
On the surface, this doesn’t seem so terrible, after all service providers may request the user’s password then throw it away after the API call has been made – but one of the important points to remember is that Twitter’s API is not located on an SSL secured server. So any calls made to Twitter’s API is made with the username and password in the HTTP header sent in plain text.
fav.or.it was recently lambasted by a blogger for doing exactly this (I’m unable to locate the URL), and we are soon going to fix the problem by launching an update that will include an SSL secured user area. Still, it amazes me that such a high profile website has been totally overlooked when it comes to this gaping security hole.
The solution to the problem is simple: Twitter, and many other API providers, need to stop requiring the password to be sent with each API call. Instead they should adopt one of the many approaches designed to circumvent this problem, be it OAuth, a challenge/response system or even a full blown token-based session system.
My favourite approach is currently LiveJournal’s challenge/response system. From a developers point of view it’s very straightforward to use and very secure. In theory, it can also be used to allow users to revoke the permission of an application.
Twitter are supposedly working on an OAuth implementation with plans to drop support for the Basic Auth 6 months after it goes live. Unfortunately, sources tell me that they’re making very slow progress, so we can’t hope for anything soon.
Update: Last night, approximately 30 minutes after I wrote this post, Twitter announced the opening of their private beta for their OAuth API. Apparently, my source got his information about 6 months ago… Is anyone aware of a sauce or condiment that goes well with my hat?
This work, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 2.0 UK: England & Wales License.
February 11th, 2009 at 9:39 pm
Surely a simpler solution would just be to incorporate an API Key system whereby each user get’s allocated a random string, their key. Both friendfeed and wordpress incorporate this method.
February 11th, 2009 at 9:55 pm
The FriendFeed system is much more secure than the plain text system, granted. However it does have the draw back that the user has to explicitly discover their “Remote Key”. This is a concept that only really power users will easily grasp and overcomplicates the process.
I prefer the LiveJournal method because you ask the user for the password once (on an SSL domain) then you get a challenge from LiveJournal. You then sign every API call with a hash of the challenge and password. The great thing about this approach is that you can easily store this hash without the worry of the password being retrievable.