Salt (Password Hashing)

What salting prevents

Hashing is deterministic, so without a salt, identical passwords produce identical hashes. A table of stored hashes then reveals which accounts share a password, cracking one of them cracks all of them, and the most common passwords stand out by how often their hash repeats before any are cracked. Precomputed tables of hashes for likely passwords can also be applied to every account at once.

Mixing a unique random value into each password before hashing removes that leak. In the words of OWASP’s Password Storage Cheat Sheet, with salting “it is impossible to determine whether two users have the same password without cracking the hashes, as the different salts will result in different hashes even if the passwords are the same.”

A single salt shared by the whole site does not provide this. Identical passwords still produce identical hashes, because every record gets the same added value. The same is true of a pepper, which is shared by design, so a pepper complements a per-record salt and does not replace one.

In practice

Modern password hashing schemes such as bcrypt and Argon2 generate the salt and store it inside the resulting hash string, so the application does not manage it separately. NIST SP 800-63B (Revision 4) requires that the salt be at least 32 bits long and chosen to minimize collisions among stored salt values.

Salts are also used outside password storage, for example in password-based key derivation under NIST SP 800-132.

History

Robert Morris and Ken Thompson described salting in “Password Security: A Case History” (Communications of the ACM, November 1979), on the Unix password scheme. When a password was set, a 12-bit random number was appended to it, and the “12-bit random quantity (called the salt)” was stored in the password file with the encrypted result. They noted it multiplied the work of testing a guess against a collection of passwords by 4,096 and made an encrypted dictionary prepared in advance impractical. They also noted the side effect that it became nearly impossible to tell whether a person had used the same password on two or more systems.

In June 2012, about 6.5 million LinkedIn password hashes were leaked. They were SHA-1 hashes without a salt. LinkedIn said afterward that its current password databases now used hashing and salting.

Sources

• Password Security: A Case History, Morris and Thompson, Communications of the ACM 22(11), November 1979. Retrieved October 2, 2026.
• Password Storage Cheat Sheet, OWASP Cheat Sheet Series. Retrieved October 2, 2026.
• NIST SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management, NIST, August 2025. Retrieved October 2, 2026.
• LinkedIn admits site hack, adds pinch of salt to passwords, The Register, June 7, 2012. Retrieved October 2, 2026.