A cryptographic salt is a public value combined with a password before hashing. Store the salt alongside the digest; secrecy is not its purpose. Its value is to make a password hash depend on more than the password alone. section 6.4.2 section 6.5
Without a salt, an attacker who obtains a database of usernames and password digests can precompute hashes for candidate passwords, then perform fast reverse lookups. Rainbow tables reduce the storage cost of this precomputation with hash chains and column-specific reduction functions. The hash function is not reversed: many possible inputs were hashed and remembered in advance. section 6.4.2 section 6.5
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 stored record includes both the digest and its plaintext salt. The salt changes the hash input, so a table prepared without that salt does not directly match the stored digest. section 6.4.2
Salting invalidates tables computed without the salt and forces attackers to build new rainbow tables for the salted inputs. It does not make a fast general-purpose hash function suitable for password storage by itself. Use a dedicated password-hashing function such as PBKDF2 or Argon2, which also require salting and are deliberately slow enough to make table construction and sharing harder. section 6.5 section 10.1.4
A leaked unsalted password database
For a site limited to six-character alphanumerical passwords, a rainbow-table implementation cracked more than 20% of password hashes. Adding a salt value before hashing forces the attacker to construct a new table rather than reuse one built for unsalted hashes. section 6.4.2 section 10.1.4




