Password Salting - Why Hashing Alone Falls Short

About 2 min read

A salt is random data added when hashing a password. Since the same password produces a different hash value when the salt differs, salts neutralize rainbow table attacks and precomputation attacks. A salt is generated uniquely for each user and stored together with the hash value.

How Salt Works, with a Numerical Example

When hashing a password, the salt is generated by a cryptographically secure random number generator and combined with the password before being fed into the hash function. For example, adding a 16-byte (128-bit) salt to the password "mypassword" produces a completely different hash value for each user even with the same password. The recommended salt length is at least 16 bytes; the standard is 128 bits in bcrypt and at least 128 bits in Argon2. As of 2025, the OWASP guidelines recommend combining Argon2id with a salt of at least 16 bytes. The salt does not need to be kept secret and is stored in the database together with the hash value. What matters is using a different salt for each user.password hashing books on Amazon explain this in detail.

Real-World Use Cases

"During a security audit, we discovered that a legacy system stored passwords without using any salt. Migrating to Argon2id with a 16-byte salt is now our highest-priority task."

Why a Salt Is Necessary

Without a salt, all users who use the same password end up with the same hash value. An attacker can use a rainbow table to crack large numbers of passwords at once. To put it in concrete numbers, without a salt an attacker can attack every user's password with a single rainbow table (on the order of a few hundred GB). However, when a 16-byte salt is used, theoretically 2 to the 128th power of tables would be required, making precomputation attacks practically impossible.

Practical Pitfalls

A common mistake is using the same salt for all users, which greatly reduces the effectiveness of neutralizing rainbow tables. Likewise, if the salt is too short (such as 4 bytes or less), an attacker can build tables covering every salt pattern. Another pitfall is trying to keep the salt "secret" by storing it in a separate location. The purpose of a salt is to ensure uniqueness, not secrecy, so there is no problem storing it in the same database as the hash value. Randomly generated passwords are inherently hard to guess, but combining them with a proper salt implementation on the service side achieves even more robust protection.authentication technology books (Amazon) are also helpful references.