Web Passwords 101
Web authentication seems to be a bit of a hot topic at the moment. In the last couple of weeks I have seen quite a few articles regarding authentication and the storing of passwords, culminating in the uproar following the Gawker network being compromised.
Jeff Atwood as written a very good analysis of the whole incident – if you haven’t read it I would highly recommend it.
I have always had a healthy respect of web authentication and all the issues around storing passwords – it strikes me as such a tricky issue that I always avoid writing my own authentication code. I think this is probably the best way of approaching web passwords – it’s pretty much impossible to cover all your bases, so rather get someone else to cover them for you!
The first rule of Fight Club
Let’s all make that the first rule of Fight Club… err… storing web passwords. And by that I mean: don’t store them! The solution to all the problems around web authentication are solved with OpenID. In local Intranet applications you can use Active Directory. The number of scenarios where you actually need to manage your own user authentication are miniscule in comparison to the number of scenarios where we are actually doing so.
How to store web passwords
I think it’s still important to know the rules around storing passwords, if for no other reason than being able to participate in this fascinating discussion. Actually, if you are a software developer you are pretty much guaranteed to be involved in numerous authentication discussions and implementations in your career.
There are enough issues around storing passwords and managing authentication to span countless blogs (as proven by the countless blogs discussing it). I’m going to attempt highlighting only the major stumbling blocks – the stuff you really really shouldn’t do.
Don’t store cleartext passwords
Please. Don’t do it. Ever. Use a hashing function.
The main reason prompting me to write this post was another post by Jeff Atwood illustrating the Mensa website’s forgotten password facility. (If you haven’t read it I encourage you to do so – it’s rather shocking/interesting)
There were also some rather… interesting comments following that post. If you don’t know the answer, I’ll help clear the air: if they can send you your current password, that means they’re storing your current password! In cleartext, no less! (The secondary issue is that they e-mail you your password – SMTP is not a secure protocol which means it can easily be intercepted) One of the commentators suggested that it’s not a big deal – the Mensa site doesn’t really store any confidential information.
This would be true in a perfect world. Unfortunately, in this world, users re-use their passwords! Again, the bigger issue is – there is no need! We never need to store cleartext passwords!
Use the right Hashing Function
Use a hashing function, and use the right one. Use one which is suited to password hashing.
Use a Salt
Unfortunately using the correct hashing function is only half the battle. Enter Rainbow tables. Rainbow tables is a rather technical way of calculating the inverse of hash functions. It uses something called pre-computed hash chains to figure out what your original password was, given the hashed value. The key here is that there is a time-memory trade-off meaning it only works for passwords that aren’t too long.
A salt is a randomly generated string which is appended to the password before passing it through the hashing function. We store the salt with the hashed value. Because each salt is different it makes rainbow table attacks infeasible.
Don’t put limits on the allowed characters
I’ve always found this one rather puzzling. Once in a while you’ll come across a site that restricts you to alphanumeric characters in your password. Not only is this a rather bizarre practice, but it’s also a massive security hole. There’s simply no need for it.
Conclusion
There is a lot more to managing passwords than what I’ve mentioned here. For example, how should password resets work? It’s important that we ask these questions and understand the dynamics involved.
When in doubt, stick to the first rule – don’t store passwords. Happy coding.