Guide: Storing Passwords Securely

I hope that all the data leaks of recent years have left an indelible mark on the minds of developers: Never store passwords in plain text in a database. Ever.

Now that this mandatory reminder is out of the way, we can move on to the heart of the matter, namely: what are the best practices for storing your users' passwords?

First of all, you need to keep in mind that regardless of the size of your site, an attacker will eventually be able to:

• Retrieve information from your database
• Gain access to the server's source code
• Automate actions to try to break in

Of course, your goal is to do everything you can to prevent this from happening, but you need to keep this information in mind when designing your password system.

Communicating over https

The first step is to secure your website (or your application) by enforcing communication over https because during registration or login, your user's password will be sent in plain text in the request.

To avoid any data interception issues, make sure that the encryption of this data is carried out using an SSL certificate, this is the first step in securing the password.

Hashing

Once it reaches the server, the password must be "hashed" before being saved in the database. Be careful, we don't encrypt (cipher) the password, we hash it—these two concepts are completely different.

Encrypted data must be able to be decrypted using the encryption key used, and one must be able to retrieve the original information intact; hashing methods are said to be "destructive."

If you're not familiar with hashes, I invite you to read my dedicated article right below!

If you want to go even further, there's a very good article on the Auth0 blog that I recommend!

A grain of salt

At first glance, when your passwords are hashed with a sufficiently secure algorithm, even if your database suffers a leak, attackers won't have direct access to plain-text passwords.

But if they manage to discover which hashing algorithm was used (which is possible), they still have the option of generating passwords and comparing them to the hashes found using techniques such as:

• Brute-force: Testing all possible combinations of different character strings
• Dictionaries: Testing combinations of words derived from personal information and common words

Some attackers even use what are called "rainbow tables," huge tables of hashes already generated (using the methods above) with the hashing algorithm found previously; these tables can sometimes weigh up to several terabytes.

To slow down (or even prevent) these attacks, we use the salting method, which consists of adding a string of characters to the password before it is hashed.

This grain of salt makes it possible to extend the length of the base password (and therefore make it longer to crack, since it's longer to generate), and to limit the use of dictionaries and rainbow tables.

Static

Static salting consists of always adding the same string of characters to all stored passwords; this grain of salt must remain secret, otherwise its effectiveness is compromised.

This technique slows down password recovery, but it doesn't prevent the use of rainbow tables, which simply need to be generated specifically for this particular site.

Dynamic

Dynamic salting consists of randomly generating a grain of salt for each user, and storing it alongside the password in the database (or, better yet, in a separate database).

This technique aims in particular to prevent the use of a rainbow table on the entire database, because since each user has a different grain of salt, it's impossible to pre-compute all the hashes for all possible grains of salt.