With salting, every password receives its own random additional value, the salt, before the password hashing function. Identical passwords therefore produce different stored hashes. A salt is not a second password and normally need not be secret; it is stored with the hash, algorithm and parameters.
How does salting work?
- When setting a password, the application generates a new salt using a cryptographically secure random generator.
- A suitable password hashing function processes password, salt and cost parameters.
- The result, salt and verification parameters are stored, never the plaintext password.
- At login, the application recomputes the hash with the stored salt and compares it in constant time.
- After successful login, it can identify old parameters and replace the hash using stronger settings.
Modern Argon2id, scrypt, bcrypt and PBKDF2 libraries normally generate and encode the salt themselves. Custom concatenation of strings and hashes is unnecessary and error-prone.
What does a salt protect against?
| Without an individual salt | With an individual salt |
|---|---|
| Identical passwords have identical hashes and are recognized immediately. | Every record has a different hash. |
| Precomputed rainbow tables can be reused across databases. | Precomputation must be repeated per salt and becomes impractical. |
| One password guess can be checked against all users together. | The attacker computes candidates separately for every user. |
A salt does not prevent guessing weak passwords after database theft. With salt and hash, an attacker can test candidates offline. The main defenses are a deliberately slow, memory-hard password hashing function with suitable parameters and strong passwords.
How do a salt and pepper differ?
A salt differs per password, may be stored publicly and prevents reuse of precomputed work. A pepper is an additional secret kept separately from the password database, for example in secret management or an HSM. It can make database-only theft harder but introduces key rotation, availability and recovery duties. It replaces neither the salt nor a suitable hash function.
How are passwords stored correctly?
- Use an established library with Argon2id; scrypt, bcrypt or PBKDF2 may be alternatives depending on platform and requirements.
- Tune time, memory and parallelism on real systems so login remains practical while offline guessing is expensive.
- Generate a new sufficiently random salt for every password change.
- Store hash format and version so parameters can be increased gradually.
- Protect login endpoints with rate limiting and MFA and reject known compromised passwords.
Which mistakes are common?
One global salt for every user removes a major benefit. A username, email address or timestamp is predictable and not a good random salt. Fast general-purpose hashes such as SHA-256 or MD5 remain unsuitable for password storage even with a salt. Encryption is not a replacement either: theft of its key reveals all passwords directly. Passwords should be verified, not recovered.
Thank you for your feedback! We will review it and optimize this content.