A salt is a unique random value added to each password before hashing, so identical passwords produce different hashes.
How a salt works
Systems should never store passwords themselves, only their hashes. Without a salt, the same password always gives the same hash – attackers can compare stolen hashes with huge precomputed tables (rainbow tables) and immediately see which users share a password. With a salt, the system generates a random value for every user, combines it with the password and stores the salt next to the resulting hash:
hash("password123" + "Q3v9...")for one user,hash("password123" + "Lm81...")for another – completely different results.
A salt is not secret. Its job is to make every hash unique, so attackers must crack each one separately. NIST guidance requires salts of at least 32 bits; in practice libraries use 16 bytes. A pepper is a different concept: a secret value stored separately from the database, for example in a hardware security module.
Why salts matter for security
Salting alone does not stop brute force on weak passwords: modern GPUs test billions of fast hashes like MD5 or SHA-256 per second. That is why salts must be combined with a slow, memory-hard password hashing function. Many data breaches have exposed unsalted or weakly hashed passwords, which were cracked within days.
Best practices
- Use a dedicated password hashing algorithm: Argon2id, scrypt, bcrypt or PBKDF2 with a high iteration count – they generate salts automatically.
- Never use plain MD5, SHA-1 or SHA-256 for passwords.
- Generate salts with a cryptographically secure random generator, unique per password.
- As a user, choose long unique passwords and a password manager – salting cannot save “123456”.
