What is salting, and what specific problem does it solve that hashing alone does not?

A salt is a random per-user value mixed into the password before hashing. It ensures identical passwords produce different hashes.

Without salt:

• Alice's password: password123 → hash xyz...
• Bob's password: password123 → hash xyz... (identical!)

If the database leaks, an attacker sees two identical hashes and instantly knows Alice and Bob share a password. Worse, they can use precomputed rainbow tables of common passwords to look up xyz... directly.

With salt:

• Alice: salt q9k3 + password password123 → hash abc...
• Bob: salt m7p1 + password password123 → hash def...

Even though they share a password, the hashes differ completely. Rainbow tables are useless because the attacker would need a separate table for every possible salt.

Two security wins:

1. Length & uniqueness: Salt extends the input length and adds entropy, so the attacker effectively faces a longer password
2. Per-user uniqueness: Even if 1,000 users picked password123, each hash is unique → must be cracked individually

Stored as: salt + hash together. Salt is NOT secret — it just needs to be unique per user.

Tip: Modern password hashing functions (bcrypt, Argon2) automatically generate and embed salts — you never need to handle them manually.

Go deeper:

• Salt (cryptography) — Wikipedia — why a unique per-user salt makes identical passwords hash differently and grows any precomputed table.
• OWASP Password Storage Cheat Sheet — implementation guidance: salting plus a slow KDF (Argon2id → scrypt → bcrypt → PBKDF2).