lock 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:



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

betwittered username and password in cookies

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


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.


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


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.

  • http://www.mightymedia.com.au Iain

    "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!"…

    • http://beerpla.net Artem Russakovskii

      Thanks, good point, Iain.

  • http://twi5.com Nischal Shetty

    oAuth FTW! 🙂

  • http://www.jaisenmathai.com Jaisen Mathai

    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.

    • http://twi5.com Nischal Shetty

      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 🙂

      • http://www.jaisenmathai.com Jaisen Mathai

        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.

    • Marcos Wright Kuhns

      While you're completely right that if a hacker gets your oAuth tokens it could give them the same rights as if they got your username & password, there are additional security and convenience advantages with oAuth. First, the tokens are unique to this site, whereas people often re-use their username & password across multiple services. Second, applications that have a good oAuth implementation will let you selectively revoke oAuth tokens. I could block the hacker who go access to my BeTwittered account while my Tweetings iPhone app, who's oAuth tokens are still secure, will not loose access. If I was forced to change my password, I'd have to re-enter them for every service connected with my Twitter account.

  • http://usedplantmachinery.org used plant machinery

    The opposite most essential factor to consider is the compatibility with the present plant. This needs to be taken care of seriously in any other case it will cost you high. Contemplating these components will assist you arrive at a final determination which is not going to solely save your cost but additionally provide added functionality.

  • Pingback: siegefall gems hack