Salting combines a password with an additional value before hashing. The salt makes precomputed password-hash tables specific to that value, so a table built for unsalted passwords cannot be reused directly against salted digests. A salt is stored in plaintext with the digest; secrecy is not its purpose. section 6.4.2
The threat is precomputation. An attacker can hash many candidate passwords in advance, retain the results in a dictionary or rainbow table, and perform fast lookups after a credential database leaks. Salting changes the input to the hash, forcing the attacker to build new tables for the added value rather than sharing one reusable table across targets. section 6.4.2 section 10.1.4
Stored password digest
Instead of storing a digest produced from a password alone, store the salt alongside the digest and include that salt whenever the password is hashed for authentication. The plaintext salt lets the system reproduce the same hash input, while making a precomputed table tied to that salt. section 6.4.2
Figure 6.9 Salts are used to make hash function output more unpredictable; the salts are stored in plaintext along with the digest values.
The diagram contrasts digest storage with salted hashing: salts accompany digest values in plaintext and make hash output less predictable for precomputation attacks. section 6.4.2
Use salting as part of password storage defense:
- Add a salt before hashing passwords to make attackers build new rainbow tables. section 10.1.4
- Do not rely on a general-purpose fast hash alone; use a dedicated password-hashing function such as PBKDF2 or Argon2, which also require salting. section 10.1.4
- Treat long, complex passwords as a separate defense because they enlarge the candidate space attackers must precompute. section 6.4.2
