With the recent hacks of LinkedIn, Last.fm and eHarmony that resulted in millions of passwords being stolen, now seems like a good time to say something about password security. I’m going to spend the rest of this blog post saying that passwords stored here are about as secure as they can be.

When you log into this website you provide an email address and a password to the server. The server then looks up the user with that email address, and then checks to see if the password is correct. This is where it gets tricky. The simplest way of doing this is by storing the password in the database, which makes checking the password when logging in trivial, except this means that all the passwords are sitting there in the database, and if anybody gets access to the database they can steal everybody’s passwords. Hopefully no unauthorised people get access to the database, but it can happen (just ask LinkedIn). The worst thing about having a password stolen is that people are lazy and reuse the same passwords, so once you have their LinkedIn password, you might also have their Facebook, email and online banking password.

Therefore, instead of storing the password itself in the database, the password is normally put through what’s called a cryptographic hash function which takes some input and always produces the same output given the same input, but it’s impossible to look at the output and work out what the input is. It turns a password like “bubbles” into “fe75bd065ff48b91c35fe8ff842f986c”, and that hash is stored in the database. Then, when somebody tries to log in, the password they entered is hashed and the two hashes are compared.

Using a hash function is all well and good, except it’s still possible to work out what somebody’s password is by putting lots of potential passwords through the hash function and seeing if any give the hash we’re looking for. This is a problem because computers are fast. It depends on which hash function is being used, but you can often test hundreds of millions of passwords per a second on a modern computer. And since a lot of people tend to use the same patterns when creating passwords, it’s possible to cut down the number of passwords you have to check dramatically by being smart — start with a word list of every word in every language, append a numeral on the end, capitalise a letter, substitute some letters for numbers (“l” for “1”), and so on, and it’s not too difficult to crack a good proportion of passwords provided you can try lots of passwords quickly.

But there is a solution — use a slow hash function. If it takes hundreds of milliseconds to test if a password generates the right hash, it’s going to take a very long time to crack any password that isn’t too obvious. There are a handful of hash functions that have been developed to be deliberately slow for just this reason, and this site uses one of them called bcrypt.

There’s one other important concept in password security that I haven’t mentioned — salt. I won’t explain it here, but having salt makes it impossible to crack lots of passwords simultaneously. LinkedIn didn’t use it, which makes it possible to crack millions of passwords in hours. However, it’s impossible to use brcypt without using salt, so you need to expend the same amount of effort on every single password, rather than doing them all at once. Between using salt and being millions of times slower than many commonly used hashing functions, bcrypt is extraordinarily secure.

So, there you have it. Even if the user database here was stolen, your password will probably remain secret. Of course, you probably don’t need to know any of these details about how passwords are stored. This is just one of those little details that should be done right, and when it is done right it will never give you anything to worry about.