What is salting?
Salting means generating a salt, a random value, for one account when its password is set and storing it next to the resulting password hash. The system hashes the salt and the password together, so the stored value depends on both. At login, the system reads the salt from the account record, hashes it with the password the user typed and compares the result with the stored hash. A new salt is generated every time the password changes.
The salt is not a secret. Its job is to make every stored hash unique, which removes the shortcuts attackers rely on when they steal a password database.
What salting defeats
Without a salt, a given password produces the same hash on every system that uses the same algorithm. That creates two weaknesses.
- Precomputed tables. Attackers can hash billions of likely passwords once, store the results in lookup tables or rainbow tables, and reuse them against every breach they obtain. With a unique salt per account they would need a separate table for every salt value, which makes precomputation pointless.
- Visible duplicates. Users who chose the same password have the same unsalted hash, so cracking one cracks them all, and the most popular passwords stand out at a glance. Salted, identical passwords produce unrelated hashes.
Salting also forces attackers to work on each account separately instead of testing every guess against the whole table at once.
A salted hash in practice
These two records belong to users who both chose the password Summer2026!. Each line holds the algorithm, the iteration count, the salt and the derived hash:
alice: pbkdf2_sha256$600000$q7Lw2ZpX9vR4mT1c$kXtRW1082I40xpiH5tnD0B28P6+0CIsLRvJ3mTXPcas=
chen: pbkdf2_sha256$600000$Hn3sK8dQ0yBf5aWe$BIXuOfRH4NKgq0pEOM6nKYqX6sGz3hR+NRvX0ipyax0=
The hashes share nothing because the salts differ. Modern password hashing functions such as bcrypt and Argon2 generate the salt automatically and keep it in the same string as the hash and cost settings. A good salt comes from a cryptographically secure random number generator; 16 bytes is typical, well above the 32-bit minimum in NIST SP 800-63B. Using the username as the salt is a known mistake, because names such as admin repeat across thousands of systems and can be precomputed.
Salt vs. pepper vs. key stretching
| Control | What it is | What it stops |
|---|---|---|
| Salt | Random, per account, stored with the hash, not secret | Precomputed tables and matching identical passwords |
| Pepper | One secret value for the whole application, kept outside the database in a vault, HSM or separate configuration | Any guessing when only the database is stolen |
| Key stretching | A deliberately slow, tunable algorithm such as bcrypt, scrypt, Argon2id or PBKDF2 | Fast guessing against each individual hash |
A salt does not make a weak password strong. An attacker holding the salt and hash can still try likely guesses against that one account, and with a fast hash such as plain SHA-256 those guesses are cheap. That is why salts are always paired with slow password hashing algorithms. Windows NT hashes are a well-known unsalted case: two accounts with the same password have the same NT hash, so precomputed tables work against them.
Salting on the CompTIA Security+ exam
Salting is part of SY0-801 objective 1.3, which deals with picking the right cryptographic technique for a job, here the right way to store passwords. Wording such as "defeat rainbow tables", "prevent precomputed hash attacks" or "several users have identical password hashes" points to a unique salt per account. If the question asks how to make brute-forcing stolen hashes slower, the answer is key stretching instead. Distractors include encrypting the password column, which is reversible and usually leaves the key nearby, switching to a longer fast hash such as SHA-512, and hash collisions, which are a different problem from duplicate hashes caused by duplicate passwords.