Salting a password means adding a unique, random value called a salt to each password before hashing it, so that identical passwords produce different hashes and precomputed attacks like rainbow tables become useless. The salt does not need to be secret; it just needs to be unique per user and unpredictable. Salting is a foundational step in secure credential storage, but it must be combined with a slow, purpose-built password hashing algorithm to be effective.
Key takeaways
- A salt is a unique random value combined with a password before hashing, defeating precomputed-hash attacks.
- Salts are not secret and are stored alongside the resulting hash.
- Every password must get its own fresh salt; never reuse a single salt across users.
- Salting alone is insufficient; pair it with a slow algorithm like bcrypt or Argon2.
- A pepper is a separate, secret site-wide value, complementary to per-user salts.
- Modern password hashes generate and embed the salt for you, reducing implementation mistakes.
What is salting a password and why does it matter?
When you store passwords, you must never keep them in plain text. Instead you store a hash. But a plain hash has a weakness: two users with the same password produce the same hash, and attackers can precompute hashes for huge dictionaries of common passwords. A salt breaks this by mixing a unique random value into each password before hashing.
The effect is that even if two users both choose password123, their stored hashes differ because their salts differ. This means an attacker cannot recognize repeated passwords across accounts and cannot reuse any precomputed work. Salting turns a one-size-fits-all attack into one that must be repeated separately for every single account.
How does a salt defend against precomputed attacks?
Attackers save time by precomputing hashes for likely passwords, storing them in lookup tables or the compressed form known as a rainbow table. When they steal a database, they simply match stolen hashes against their table.
A unique salt destroys this strategy. Because the salt is different for every password, an attacker would need a separate precomputed table for every possible salt value, which is computationally infeasible when salts are large and random. The attacker is forced to attack each salted hash individually, and any precomputation they did in advance is worthless. This is why the salt’s uniqueness, not its secrecy, is what provides the protection.
How is salting different from peppering?
Salting and peppering are complementary defenses that people often confuse.
| Property | Salt | Pepper |
|---|---|---|
| Uniqueness | Unique per password | Single value shared site-wide |
| Secrecy | Not secret; stored with hash | Secret; stored separately |
| Storage location | Database, next to the hash | Environment variable, config, or HSM |
| Main purpose | Defeat precomputation and duplicate detection | Add a secret even if the database leaks |
A pepper adds value only if it is kept out of the database, so that a database-only breach still leaves attackers missing a secret. It supplements salting rather than replacing it.
How do you salt a password correctly?
Correct salting has a few firm rules:
- Generate the salt with a cryptographically secure random number generator, not a general-purpose
rand(). - Use a fresh salt for every password, including when a user changes their password.
- Make the salt long enough to be globally unique; at least 16 random bytes is a common recommendation.
- Store the salt with the hash so you can recompute the hash at login time.
In practice you rarely do this by hand. Purpose-built password hashing functions handle salting internally. For example, calling a bcrypt or Argon2 library to hash a password automatically creates a random salt and packs it into the output string, so you store just that one value.
Why isn’t salting alone enough?
Salting stops attackers from reusing precomputed work, but it does nothing to slow down guessing a single password. If you salt a password and then run it through a fast general-purpose hash, an attacker who has the salt can still try billions of guesses per second on modern hardware.
The missing ingredient is cost. Secure password storage deliberately uses slow algorithms designed to be expensive to compute, such as bcrypt, scrypt, and Argon2. These functions include a tunable work factor so each guess takes meaningful time and, in the case of scrypt and Argon2, meaningful memory. Salting plus a slow, memory-hard hash is the combination that actually protects passwords. Never use a fast hash such as a plain general-purpose digest for passwords, even with a salt.
What are common salting mistakes?
- Using one global salt. A single shared salt lets attackers attack all identical passwords together and precompute against that one value.
- Deriving salts from usernames or emails. Predictable salts can be precomputed in advance, undermining the whole point.
- Using a non-cryptographic random source. Weak randomness can produce guessable or repeating salts.
- Salting but using a fast hash. This leaves you exposed to high-speed brute force; you need a slow, salted algorithm.
- Reusing the same salt after a password change. Always regenerate the salt so old and new hashes differ.
- Rolling your own scheme. Custom salt-and-hash constructions are error-prone; use a vetted password hashing library.
How do modern password hashes handle salting automatically?
The safest approach is to let a modern algorithm do the work. Functions like bcrypt and Argon2 generate a secure random salt for each password and embed it, along with the algorithm parameters, directly in the encoded hash string they return. When a user logs in, you pass their submitted password and the stored string to the library’s verify function, which extracts the salt and parameters, recomputes the hash, and compares it in constant time.
This design means application developers usually never touch salts directly. You store the single self-describing output string, and the salt, cost factor, and algorithm version travel with it. Relying on these libraries eliminates the most common salting mistakes and keeps you aligned with current best practice: unique salts, slow hashing, and safe verification handled for you.
Frequently asked questions
Does a salt need to be secret?
No. A salt is not a secret and is stored alongside the hash. Its purpose is uniqueness, not confidentiality, so it defeats precomputed attacks even when known.
Should each user have a different salt?
Yes. A unique random salt per password is essential. Reusing one salt for everyone lets attackers attack all matching hashes at once.
Is salting alone enough to protect passwords?
No. Salting stops precomputation, but you still need a slow, deliberately expensive hash like bcrypt or Argon2 to resist brute-force guessing.
What is the difference between a salt and a pepper?
A salt is unique per user and stored with the hash; a pepper is a single secret kept separately, such as in an environment variable or HSM, and applied to all passwords.
How long should a salt be?
Long enough to be globally unique and unpredictable. A random value of at least 16 bytes from a cryptographically secure generator is a common, safe choice.
Where do I store the salt?
Typically alongside the hash in the same database record. Modern password hashes like bcrypt and Argon2 embed the salt inside the output string automatically.
Can I derive the salt from the username?
You should not. Predictable salts based on usernames or emails weaken the protection because attackers can precompute against them; use random salts.