Security – Password Hashing

When you have a site, an app, or application, you will inevitably have users who use it. Those users must, of course, log in with a username and password. Your app must, of course, store those usernames and passwords in order to do the authentication. This places a hefty burden of responsibility on your shoulders.

It is up to you to ensure that your users’ private information cannot be stolen, and that only those users may use your app with their accounts. This may not be very important if your app only offers a tool for use (eg: a colour picker or weight calculator), but as soon as you store any information at all about your users, or worse, you provide them any service that acts with or costs money, you need to be very careful.

You will probably need to store these passwords in a database. Your first task is to secure the database, to ensure that no hackers can gain access to the data. You should definitely take every security precaution with the database, but history has shown us that this really is never enough. So many of the most secure databases in the world have been compromised over the years – we need to accept this truth: a truly dedicated hacker will get the data, with enough motivation and time.

So, your next step must be to secure the passwords themselves. It doesn’t help to encrypt the passwords. For that to work, you need a key, which must necessarily be stored on the same server as the data (or at least be available when the passwords are decrypted). Anyone who has access to the data will probably also have access to the key, making the encryption useless. We’ve only made the job slightly harder.

The approach most commonly taken is to hash the passwords. Hashing is a process of one-way encrypting the password, so it cannot ever be decrypted. The key to hashing is that the same password will always result in the same key. So, when a user tries to log in with a password, you hash that, then compare it to the hashed password in your database. If they match – voila.

Choosing the right hashing algorithm is important. You need to choose one that minimises predictability. If the hashing algorithm makes all 6 letter words into 12 character hashes, and 7 letter words into 14 character hashes, a hacker can quickly narrow down his search to only words of a certain length. This is obviously an over-simplified example (and inaccurate, since hashing algorithms always make the same size hash, no matter how long the source string), but the idea stands; if the algorithm produces hashes that contain predictable patterns, hackers can write their own counter-algorithms to find those patterns and use them to match hashes to words.

You also need to make sure you use the latest hashing algorithms. The security industry is in a constant cat-and-mouse game with hackers; security creates a new algorithm, then hackers find a vulnerability with that algorithm. Security then creates a better algorithm, then hackers find a way around that one too. A quick Google search will find you the best algorithm to use today, but remember to keep that up-to-date every few years.

Is that enough? Can we just hash and save? Nope – even the best hashing algorithm will still produce the same hash for the same password. So If I know the hashes for common password (and it is really easy to create those), I can simply scan the database for any of those, and I know immediately what the passwords are for those accounts. To get around this, we use a technique called salting.

Salting a password involves modifying that password in a predictable way that is unique to that database. You would typically generate a random salt, usually quite long, which is stored with the password. (Remember that the attacker probably has access to your source code, so they almost certainly know your salting technique. You may as well just save the salt, but make it long and complicated.) The aim is to change the password in a predictable way such that you can repeat it whenever you need to check the password, but the hash in your database for that password is not the same as the hash a hacker would have using the same algorithm.

Salting means a hacker cannot just use a known database of password hashes. Assuming they can work out your salting technique, they’ll still have to generate a whole new database of hashes for comparison; a significantly more imposing problem.

So, to sum up: If you have an app that needs to store user credentials, please, please, please make sure you hash and salt your passwords. Or, better yet, use an authentication service which will worry about these things for you. Google, Facebook and GitHub all offer these services.