What Is a Salt in Password Hashing?

If you've read anything about storing passwords, you've seen the word "salt." It's a small idea with a big impact on security. This guide explains what a salt is, the attack it defeats, and how it relates to bcrypt and peppers.

What is a salt?

A salt is a random value added to a password before it's hashed. Instead of storing hash(password), you store hash(password + salt), along with the salt itself. Each user gets a different, randomly generated salt. The salt isn't secret — it's stored next to the hash — its job is to make every hash unique.

The problem salts solve

Without a salt, the same password always produces the same hash. That creates two weaknesses. First, if two users pick the same password, their stored hashes are identical — visible to anyone who steals the database. Second, and more seriously, attackers can precompute the hashes of millions of common passwords into giant lookup tables called rainbow tables, then instantly match them against a stolen hash.

How a salt defeats rainbow tables

Because each password is combined with a unique random salt, identical passwords produce different hashes. A precomputed rainbow table is useless: the attacker would need a separate table for every possible salt, which is computationally impossible. Salting forces attackers to crack each hash individually rather than looking them all up at once.

Why every salt must be unique

Reusing one salt across all users would still let an attacker build a single table for that salt and crack everyone at once. A unique, random salt per password is what makes the defense work. Generate salts from a cryptographic random source — the same kind of randomness behind our API key generator.

Salting is built into modern password hashes

The good news: you usually don't manage salts yourself. Algorithms like bcrypt, scrypt and Argon2 generate a random salt automatically and store it inside the hash output. A bcrypt string like $2b$12$N9qo8uLO... contains the algorithm, cost, salt and hash all together, so the verifier has everything it needs. That's one reason these are the right tools for passwords — see bcrypt vs SHA-256.

Salt vs pepper

A pepper is related but different: it's a secret value added to every password (in addition to the per-user salt), and — crucially — it's not stored with the hash. It's kept separately, for example in application config or an HSM. The idea is that even if the database leaks, the attacker is missing the pepper. Salts defeat precomputation; a pepper adds a secret the database alone doesn't reveal. Peppers are optional and add operational complexity, while salting is essential and non-negotiable.

Try it

Generate two bcrypt hashes of the same password with our bcrypt generator and notice they're completely different — that's the salt at work. Create strong passwords to hash with the password generator.