What Is a Rainbow Table? Password Attacks Explained

A rainbow table is a precomputed data structure that trades storage space for cracking speed: instead of hashing every candidate password at attack time, an attacker looks up a stolen hash against a table built in advance, and reads off the matching plaintext almost instantly.

The problem it solves

Cracking a password hash the naive way — hashing every candidate password and comparing it to the target — is slow, especially against a large set of stolen hashes. The obvious speedup is to precompute a full table mapping every possible hash to its plaintext ahead of time, so an attack becomes a single lookup. But a full lookup table for even a modest password space is enormous: storing every plaintext-hash pair for all reasonably likely passwords would take more storage than is practical. Rainbow tables are a compression trick that keeps the lookup-speed benefit while shrinking the storage cost by orders of magnitude.

Hash chains and the reduction function

The compression works through chains. Starting from some plaintext candidate, the attacker hashes it, then applies a reduction function — a function that maps a hash back into something that looks like a plaintext password (not a true inverse, just a deterministic remapping). That output is hashed again, reduced again, and the cycle repeats for a fixed chain length, alternating hash and reduce.

Only the very first plaintext and the very last hash of each chain are stored — everything in between is discarded. A single stored pair now represents an entire chain of intermediate plaintext-hash relationships, which is where the storage savings come from: a table with a modest number of chains can implicitly cover a vastly larger number of password guesses than it explicitly stores.

How a lookup works

To crack a stolen hash, the attacker checks whether it matches any chain’s stored endpoint. If not, they apply the reduction function and hash again, checking again, repeating up to the chain length — effectively simulating where in some chain this hash could have appeared. Once a match against a stored endpoint turns up, the attacker regenerates that entire chain from its stored starting plaintext, replaying the hash-then-reduce cycle until the target hash reappears — and the plaintext that produced it is the cracked password.

This costs some computation per lookup (replaying a chain), but far less than hashing the entire password space from scratch, and at a fraction of the storage a full lookup table would need.

Why salting defeats rainbow tables

A salt is random data mixed into a password before hashing, unique per stored credential, so two users with the identical password end up with completely different stored hashes. Password hashing with a salt breaks rainbow tables at the root: a precomputed table only works because it was built against one specific hash function with no salt, or a small number of known salts. Once every password in a database is salted with its own random value, an attacker would need a separate rainbow table per salt — which is exactly as expensive as the full lookup table the rainbow table was invented to avoid, multiplied by every distinct salt in the database.

That’s why any modern password storage scheme salts by default, and why finding an unsalted hash in a breached database is treated as a serious red flag.

Rainbow tables vs brute force vs dictionary attacks

Technique	Precomputation cost	Per-hash lookup cost	Effective against salted hashes
Brute force	None	Very high	Yes, but slow either way
Dictionary attack	Small (wordlist)	Low, but limited to the wordlist	Yes, but slow either way
Rainbow table	High, done once	Very low	No — a table would be needed per salt

Brute force and dictionary attacks recompute hashes at attack time, so they’re unaffected by whether a rainbow table exists — they’re just generally slow against a well-chosen hashing algorithm regardless of salting. Rainbow tables specifically target the case where an attacker can amortize precomputation across many targets sharing the same unsalted hash function, which salting eliminates.

Why modern hashing algorithms make them irrelevant twice over

Even setting salting aside, rainbow tables assume the underlying hash function is cheap to compute — fast general-purpose hashes like plain SHA-256 can be evaluated billions of times per second on commodity hardware, which is exactly what makes precomputing a table (or brute-forcing directly) tractable in the first place. Password-specific hashing algorithms like bcrypt and Argon2 are deliberately slow and memory-hard, which raises the cost of generating a rainbow table’s chains so much that building one becomes impractical even before salting is considered. Combined with mandatory per-password salting, rainbow tables are effectively obsolete against any system following current password-storage practice — which is also why layered defenses like multi-factor authentication matter regardless: they reduce the damage from any single cracked credential, salted or not.

The takeaway

A rainbow table precomputes chains of hash-and-reduce cycles, storing only chain endpoints, so an attacker can look up a stolen hash and replay a chain to recover the plaintext instead of hashing every candidate from scratch. Salting neutralizes the entire technique by forcing a separate table per salt, and slow, memory-hard hashing algorithms like bcrypt and Argon2 make even generating one table too expensive to bother with. The practical defense hasn’t changed: salt every password hash, use an algorithm designed to be slow, and never store or transmit passwords in a form that lets any of this become relevant.