Salts and hashes: How apps and websites protect your passwords

Password protection methods like Diceware, password managers, and two-factor authentication are just one side of the story. What are apps and websites doing on their end to protect your passwords?

Here we’ll talk about password salting and how it keeps your passwords safe from attacks. But to talk about salting, we need to talk about hashing. And to talk about hashing, we need to talk about plaintext.

Plaintext is plain wrong for passwords

In cryptography, when we say data is stored in “plaintext,” we mean that it is sitting in a file—like a text file or spreadsheet on your computer—unaltered and fully readable. It should go without saying that websites shouldn’t store passwords like this (although it occasionally happens, even at Google).

One might think the solution is for a website to encrypt your passwords, but in practice this just kicks the problem further down the road. Encrypted data has a key, and how do you store the key that unlocks your key? With another key? You see the problem.

The solution is called hashing.

What is password hashing?

A hash function is an algorithm that transforms any password into a seemingly random string of bits.

Unlike with encryption—which by definition can be decrypted—there is no reverse version of this process: it is a one-way function.

It might be hard to imagine a mathematical process that cannot be reversed. But think of how you can easily add up all the digits in a large number (such as 9,807,347) to get a sum (38), but you cannot use the sum to calculate the original number. Password hashing is just a more sophisticated version of that.

Hashing also usually adds length, which is a simple defense against brute-force attacks. In the case of SHA-256, a popular hashing algorithm, the hashed password is always 256-bits long (64 characters in hexadecimal), no matter the length of the original password. Another algorithm is MD5, which produces 128-bit hashes.

Storing passwords as hashes instead of plaintext is a powerful innovation because it allows the website to have no knowledge of the password itself. After all, the website doesn’t need to know what your password is; only that you have entered it correctly. To do this, it simply hashes whatever you type into the password field and checks if it’s the same as what’s in their database.

Ever forgotten a password and wondered why the website forces you to create a new one? Why can’t it just tell you what the old one was? Probably because it never knew what it was in the first place, thanks to hashing.

Is hashing safe for passwords? Here’s why it’s not enough

Hashing by itself is susceptible to a common relative of brute-force attacks called a rainbow table attack, which takes advantage of two facts: 1) people often reuse their passwords, and 2) the same password hashed with the same algorithm will always produce the same result.

The attack starts with a rainbow table: a list of previously used passwords—short passwords, common words, and old passwords exposed in data breaches—and their hashes. When an attacker finds a new database of hashed passwords, he can easily check if any of them match one of the hashes in his rainbow table and thus find the original password.

As an end-user, you can avoid this happening to you by using unique passwords for every account.

There is a way, however, for apps and websites to guard against rainbow table attacks even when their users don’t use unique passwords: by salting their passwords before hashing.

What is password salting?

A salt is a unique, randomly generated string of characters, added to the beginning or end of a password. When the hash function is applied to this combination, the result is called a salted hash.

Salting solves the reused password problem because adding different salts to the same password results in different hashes:

The beauty of salting is that the salt for each password can be stored in plaintext alongside its hash without jeopardizing the original password (although they can be stored separately, in which case it is called a pepper). Salts can be stored with hashes because even if an attacker knows what salt goes with what hash, he still won’t be able to reverse the process and compute the original password.

Though it is theoretically possible to precompute a rainbow table for every possible salt, in practice this is prohibitively time-consuming, provided the salts are long and unique.

Does salting hashes mean I can safely reuse passwords now?

Unfortunately, no! Salted hashes are a safeguard against attackers who exploit reused passwords, but you should never assume that every app and website you use is salting their databases properly, or at all.

Your best defense against attacks is to generate your own unique, random passwords for each online account, and the best way to do that is with a password manager.