How *Not* To Implement A Web Application That Handles External Authentication, Using BeTwittered.com As An Example
| Share |
Today I'm going to look at how not to handle user authentication in a web application, taking BeTwittered.com authenticating with Twitter as an example (sorry, guys).
BeTwittered is a simple and comfortable gadget that you can add to your site, such as your iGoogle homepage.
Since BeTwittered is just a bridge between you and Twitter, it has to first log you into your account. Here is where things go horribly, horribly wrong.
1. BeTwittered does not use SSL to secure requests to its servers
All authentication information is transmitted to BeTwittered servers in plain text and is easily sniffable by an attacker, both on your own network and outside of it. You can read more about SSL encryption here.
Since BeTwittered passes your Twitter username and password unencrypted as GET parameters, it may as well be serving them to potential attackers on a silver platter (note that passing this data in a POST request would change nothing, security-wise).
Here is an example request:
http://betwittered.com/api/?_=1265242511260&req=verify_credentials&username=foo&password=bar
Ugh…
2. BeTwittered stores your username and password in unencrypted cookies
Because BeTwittered tries to keep you logged into Twitter, it caches the username and password, unencrypted, inside browser cookies.
This means that an attacker needs to simply look at your cookies to steal this information. This can be done using these methods, among others:
- using an XSS vulnerability
- sniffing the network traffic
- walking up to your computer
3. Because BeTwittered passes your authentication information to its servers, it's already insecure
If someone gets access to BeTwittered servers, it's safe to assume at that time that all accounts are potentially compromised.
Smaller sites generally cannot dedicate appropriate resources to securing their servers, which can make breaching them easier for hackers. Even Twitter itself was hacked numerous times.
The Alternative Solution
oAuth
If the endpoint application supports oAuth (Twitter has for months), do us all a favor and use it. Please.
oAuth allows delegating authentication to Twitter itself and only giving the application easily revokable limited access.
If BeTwittered were using oAuth, the user would be redirected to Twitter, where he or she would login. Then, the user would be sent back to BeTwittered, but now bearing special tokens. Any requests to Twitter would then be accompanied by these tokens, which would be validated by Twitter every time they're used – all of this without ever passing your password around.
You can find a nice overview of the oAuth architecture here.
Otherwise
If the endpoint application doesn't support oAuth, then
- use SSL encryption (https)
- store the authentication information on the server side instead of the client side in a cookie. Instead, use the cookie to store some sort of an internal ID pointing to this server-side data. Alternatively, encrypt the username and password via a secure salted two-way hash and only then store the encrypted version in a cookie
- make sure to stay on top of securing your servers (and give your sysadmin a raise). It's a time-consuming commitment, please take it seriously
Conclusion
What other secure authentication technique or tips do you know about? Feel free to share in the comments.
Oh, and this goes without saying – stop using BeTwittered, at least until they implement a more secure login option. I've alerted the creators about the issue and also started these threads on HN and Reddit.
Artem Russakovskii is a San Francisco programmer, blogger, and future millionaire (that last part is in the works). Follow Artem on Twitter (@ArtemR) or subscribe to the RSS feed.
In the meantime, if you found this article useful, feel free to buy me a cup of coffee below.
beer planet is a blog about technology, programming, computers, and geek life. It is run by Artem Russakovskii - a local San Francisco geek who currently works at 
Artem loves commenting on other people's blogs and reading comments on his own, so go ahead and leave one.
"note that passing this data in a POST request would change nothing, security-wise"
At least using POST would mean the plain text passwords weren't quite so likely to end up in webserver logs or proxy server logs… But yeah, as the kiddies say "yr doin it wrong!"…
Thanks, good point, Iain.
oAuth FTW!
Just wanted to point out that oauth tokens aren't much different than a user's username and password. If you grant an application, on Twitter for example, with read and write access then anyone with the tokens and the private secret can have their way with your account.
This is far better than handing over a username and password but it's important to remember that oAuth alone doesn't solve security problems. It still takes common sense to implement oAuth correctly (albiet some of that is taken care of by the oAuth spec).
Tokens should be treated like passwords that need to be decrypted using salt or other means to secure them.
Umm… not really… you would also need the consumer secret!
Of course, nothing is completely safe, but this can make it a little more difficult
Consumer secret is what I meant by "private secret". I agree that security by obfuscation is very valid as long as you're aware that's partly what it is. I'm a huge fan of oAuth. It's just that I think it's important not to get to comfortable with anything security related.