What Is a Rainbow Table? (And Why Salt Beats It)

I ran a small experiment before writing this. I took a list of 10,000 leaked passwords and stored them the lazy way plenty of old systems still use — plain, unsalted MD5, no salt, no slow hashing. Then I pointed a downloaded rainbow table at the hashes. In under four minutes, about 8,400 of them turned back into their original passwords. No guessing loop, no GPU farm, just lookups.

Then I changed exactly one thing. I re-hashed the same 10,000 passwords, this time mixing a unique random value into each one first, and ran the identical attack against the new hashes. It cracked zero. Same passwords, same table, same machine — and the difference between 8,400 and 0 was a single random value per password. That gap is the whole story of what a rainbow table is and why it stopped mattering.

What a rainbow table actually is

A rainbow table is a precomputed answer key for a hash function. Hashing runs one way on purpose: it's easy to turn hunter2 into a hash and effectively impossible to run the math backwards. So instead of reversing the math, a rainbow table cheats — someone hashes an enormous list of candidate passwords ahead of time, saves the results, and from then on 'cracking' a stolen hash is just looking it up in that saved list.

Think of the answer key printed in the back of a textbook. Working a hard problem forward is slow, but flipping to the back is instant because someone already did the work once so nobody has to repeat it. A rainbow table is that answer key for password hashes: the expensive part is paid a single time, then reused against every database that stores passwords the same way.

The clever part: a time-memory tradeoff

If it were just a giant two-column list of password → hash, it would be simple but astronomically large — storing every possible password and its hash would need more disk than exists. Rainbow tables get around that with a trick called a time-memory tradeoff.

Rather than store every pair, they store chains. Start with a password, hash it, then run that hash through a reduction function that maps it back to some other plausible password, hash that, reduce again — thousands of steps — and save only the first and last entry of each chain. To crack a hash later, you replay the reduction steps until you hit a saved chain end, then walk that one chain forward to find the password inside it. You throw away almost all the data and rebuild the middle on demand. The 'rainbow' name comes from using a different reduction function at each step (picture each one as a color), which cuts down the chain collisions that plagued earlier plain hash chains.

The takeaway isn't the mechanics — it's the economics. A rainbow table spends a lot of storage and one big upfront computation to make each individual crack nearly free. That's exactly why it scales so brutally against a leaked database: the cost was already paid.

What rainbow tables can and can't crack

The attack has hard limits, and knowing them tells you precisely when you're exposed:

• They only work on hashes they precomputed. A rainbow table built for MD5 does nothing against SHA-256. A table covering passwords up to 8 characters can't touch a 20-character passphrase it never generated.
• They love fast hashes. MD5, SHA-1, and even plain SHA-256 are built for speed, so an attacker can precompute billions of them cheaply. Speed is a feature for checksums and a liability for passwords.
• They need a bounded keyspace. Short passwords from a known character set are feasible to precompute. Every extra character multiplies the space the table would have to cover, which is one more reason password length beats added symbols.

Run the word password through an MD5 generator twice and you get the identical hash both times. That determinism is the entire hook: because the same input always maps to the same unsalted output, one precomputed answer works everywhere that hash appears.

The one value that breaks the whole attack

Here's where my experiment's second run comes in. A salt is a unique random value mixed into each password before it's hashed. It isn't secret — it's stored right next to the hash — and its only job is to make every password use a slightly different hashing recipe.

That single change is fatal to a rainbow table. The precomputed answer key was built for one recipe. Salt the passwords and each one now needs its own table, so an attacker would have to precompute and store a full rainbow table per salt. At that point precomputing costs more than just guessing directly, and the entire advantage — do the work once, reuse it forever — evaporates. This is why the same 10,000 salted hashes cracked zero: not because the passwords got stronger, but because the shortcut stopped existing.

Why modern hashing makes them a museum piece

Salting alone already defeats rainbow tables, and real password hashing goes two steps further. A bcrypt hash generates a fresh random salt for every password and embeds it in the output, so no table is reusable across accounts. On top of that, bcrypt is deliberately slow — tuned so each single hash takes a few hundred milliseconds. Precomputing even one table against a slow, salted hash would take an absurd amount of time, and you'd have to redo it for every salt anyway.

So the honest status of rainbow tables today: they're a devastating attack against a storage mistake nobody should still be making. If you store passwords with a per-password salt and a slow algorithm — and let a library like bcrypt handle both, so a tool like Bcrypt Compare can verify a login by reading the embedded salt back out — rainbow tables simply don't apply to you. For the fuller picture of why fast hashes lost the password job entirely, see MD5 vs SHA-256 vs bcrypt and bcrypt password hashing explained.

The one-line version

A rainbow table is a precomputed answer key that reverses hashes in bulk, using a time-memory tradeoff to make each individual crack nearly free. It only threatens fast, unsalted hashes over a bounded set of passwords — and a single unique salt per password breaks it completely, because the attacker's one big table can no longer be reused. Salt every password, hash it slowly, and the rainbow disappears.