Why does salting specifically defeat rainbow tables, even though rainbow tables are precomputed and stored?

Rainbow tables are built for unsalted hashes — adding a salt forces the attacker to rebuild the entire table per salt, which is computationally infeasible.

The math:

A standard rainbow table for 8-char alphanumeric passwords might take weeks to compute and hundreds of GBs. It's a one-time investment that lets you crack many hashes.

If passwords are salted with a 16-bit salt (65,536 possibilities), the attacker needs 65,536 separate rainbow tables — multiply storage and compute by 65,536.

With a 32-bit salt (~4 billion possibilities), you need 4 billion tables. Storage explodes from 100 GB to 400 exabytes — physically impossible.

Why the salt doesn't need to be secret:

The salt is stored alongside the hash in the database. Even if the attacker has it, they still need to do online cracking per user — they can't reuse a precomputed table because every user's salt is different.

Real-world salt sizes:

• bcrypt: 128-bit salt (16 bytes) — completely defeats rainbow tables
• Modern systems: 256-bit salts via cryptographic RNG

Key insight:

Salting transforms the attacker's problem from "look up in a precomputed table" to "brute-force each user individually." The total work explodes by N (number of users).

Tip: This is why even a poorly-chosen password gains protection from salting — attackers must crack it from scratch instead of looking it up in seconds.