Password Storage

Heya,

So you’ve decided you want to store passwords yourself and that there is no way to let a framework or CIAM system take care of this instead?

Okay, let’s talk through it. But remember that I warned you.

Password Storage Requirements

The first thing to do is pick a hashing algorithm. Never store a password in plain text or as an encrypted value.

The difference between storing passwords as encrypted and hashed values is that with encryption, you can retrieve the plaintext password value with the key. Or, critically, an attacker could retrieve the passwords and use them in a credential stuffing attempt.

With hashing, it’s a one-way street. You can verify if a user-supplied password matches, but you can never get the password back from the hashed value.

OWASP has suggestions on the hashing algorithm. Argon2 is one option, PBKDF2 is another. These offer trade-offs in terms of security, speed, CPU intensity, and memory usage. Pick the one that best suits your needs. Consider how many logins per second you want to support and how worried you are about attacks.

NIST also offers hashing algorithm guidance but the last published release was in 2010. There is a revision of this document in process, which began in 2023, but it is unclear to me where this is.

Once you’ve selected a hashing algorithm, pick a work factor. “Work factor” is a fancy way of saying how many times to apply this hashing algorithm to a single plaintext value. Hashing password values once is not effective, because an attacker can quickly build up a list of plaintext → hashed values. If they steal your hashed passwords, they can work backwards to the plaintext.

With a high factor, you’re balancing between making it hard for someone to brute force passwords. You need hashing to take time, but you also want it to be fast enough that it doesn’t impact your system or its legitimate users. The appropriate factor depends on your algorithm.

The work factor should also change over time. This is because hardware improves, so picking a factor is not a one-and-done choice.

Now that you have your hashing algorithm and work factor, plan to add a random string to every password. This is called the salt. Each user should have a unique salt, and it is typically stored in the database with the password hash. Using a salt prevents what are called rainbow table attacks, which precalculate common passwords with given algorithms and work factors. Humans, as it turns out, are not very good at picking random values. If you add random data to the password value before it is hashed, such precalculation becomes more difficult.

You can also increase the safety of passwords by adding a pepper. A pepper is similar to a salt in that it is a value appended to the password string. But instead of storing a random value in the database next to the hashed password, the pepper is stored somewhere else, such as in a dedicated cryptographic hardware module. This makes it more difficult for an attacker who gets access to your database (or a database backup) to work backwards to the plaintext password value. Not every system uses a pepper, as it adds complexity. Determine what makes sense for your system.

Finally, encrypt your database or data storage solution at rest. In cloud environments, this is often as simple as configuring a flag on database creation. This is part of a defense in depth strategy. If someone steals the backup of your disk image, this prevents them from getting access to the hashes.

Implications

All of these storage complexities apply to any data that you want to verify the user holds but also want to be opaque to other parts of your system, though passwords are a very common example. These mechanisms affect how you can interact with the plain text value.