Cybersecurity glossary
What is a Salt (Cryptography)?
Learn what a cryptographic salt is, why unique random salts protect password hashes from rainbow tables, how salts differ from peppers, and how to store salts correctly with adaptive hashing.
Definition
In cryptography, a salt is random data mixed with a password (or other secret) before hashing so that identical inputs produce different digests, defeating precomputed rainbow-table attacks and ensuring per-credential uniqueness.
Why salts matter
If every password were hashed alone with a fast algorithm, identical passwords would produce identical digests. Attackers could build rainbow tables once and crack many accounts instantly.
A cryptographic salt breaks that pattern. By mixing unique random data into each hash, salts ensure Password123! for Alice looks nothing like Password123! for Bob in storage—and precomputation becomes far less effective.
How salting works with password hashing
Generate a random salt
Create a unique salt with a cryptographically secure random number generator.
Combine salt and password
The password-hashing function mixes salt and password according to its design.
Derive the digest slowly
Adaptive algorithms apply CPU/memory cost so offline guessing is expensive.
Store salt with the hash
Persist algorithm parameters, salt, and digest together for later verification.
Verify on login
Recompute using the stored salt and compare digests in constant time.
Never reuse salts
Each new password or rotation gets a freshly generated salt.
Salt vs pepper vs encryption key
| Item | Kept secret? | Scope |
|---|---|---|
| Salt | Usually no (stored with hash) | Per password |
| Pepper | Yes | Application/HSM-wide |
| Encryption key | Yes | Used to encrypt/decrypt—not a substitute for hashing passwords |
What salts do not fix
Weak passwords
Salts do not stop guessing `Welcome1` if the attacker targets one hash at a time.
Fast hash algorithms
MD5(password+salt) is still too fast for modern password storage.
Predictable salts
Usernames or timestamps used as salts undermine uniqueness and entropy.
Plaintext logging
Salting storage does not help if passwords are logged elsewhere in cleartext.
Practical checklist
- Use a modern password-hashing library that generates unique salts automatically.
- Never roll your own salt+SHA scheme for password storage.
- Ensure salts are long, random, and unique per credential.
- Store salts with hashes; protect the database with ordinary access controls.
- Consider a pepper only as an extra layer with careful key management.
- Combine salting with breached-password checks and MFA.
- Re-hash with new salts when users change passwords.
- Audit legacy systems for unsalted or globally salted password tables.
The practical takeaway
A salt is random per-password data mixed into hashing so identical passwords do not share digests and rainbow tables lose effectiveness. Salts are necessary—not sufficient—for safe password storage.
Use unique random salts via modern adaptive algorithms, keep peppers/keys separate if used, and remember that weak passwords still fall to focused offline guessing.
Related security terms
Password Hashing
The broader practice of storing passwords as slow, salted digests.
Brute-Force Attack
Offline guessing against stolen hashes remains relevant even with salts.
Credential Stuffing
Attacks that become easier if password databases are stored without proper hashing/salts.
Broken Authentication
Weak credential storage is a core authentication failure.
Frequently asked questions
What is a salt in simple terms?
A salt is a random value added to a password before hashing. It makes sure two users with the same password do not end up with the same stored hash.
Why are salts important?
Without salts, attackers can precompute hashes for common passwords once and reuse them against many users. Unique salts force attackers to attack each hash individually.
Should salts be secret?
Salts must be unique and unpredictable, but they are usually stored alongside the hash and are not treated as secret like a pepper or encryption key.
What is the difference between a salt and a pepper?
A salt is per-password and stored with the hash. A pepper is a secret application-wide (or HSM-held) value mixed in and kept confidential.
How long should a salt be?
Use a cryptographically random salt of sufficient length—commonly at least 16 bytes—generated by a secure RNG. Follow your password-hashing library’s defaults when they are modern.
Can I use one global salt for everyone?
No. A single shared salt still lets attackers amortize work across users more easily. Each password needs its own salt.
Do modern algorithms handle salts automatically?
Yes. Libraries for bcrypt, scrypt, Argon2, and PBKDF2 generate and encode salts into the stored hash string. Prefer those libraries over hand-rolled schemes.
References
Explore authoritative guidance and frameworks related to salt (cryptography).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.