A rainbow table is a precomputed data structure that lets attackers recover passwords from unsalted hashes much faster than computing every hash during the attack.
How rainbow tables work
Cracking a hash normally means hashing candidate passwords until one matches. Storing a ready lookup table of every password and its hash would be fast but would need enormous storage. Rainbow tables, introduced by Philippe Oechslin in 2003 and building on Martin Hellman’s 1980 time–memory trade-off, find a middle ground:
- The table consists of chains: a password is hashed, the hash is turned back into a new candidate by a “reduction function”, which is hashed again, and so on thousands of times.
- Only the first and last value of each chain is stored, which saves huge amounts of space.
- To crack a hash, the attacker recomputes the chain from that hash and looks for a matching end point, then regenerates the chain to find the password.
Each table works only for one hash algorithm and a defined character set and length. Tools such as RainbowCrack and Ophcrack made the method popular, especially against Windows LM and NTLM hashes, which are not salted.
Why rainbow tables matter
Against unsalted fast hashes such as MD5, SHA-1 or NTLM, rainbow tables reduce cracking time for short passwords from days to minutes. Many old website breaches exposed exactly such hashes. Today GPU-based dictionary attacks with Hashcat are often faster and more flexible, but rainbow tables remain a textbook example of why hash storage design matters.
How to protect against rainbow tables
- Add a unique random salt to every password before hashing – this makes precomputed tables useless.
- Use dedicated password hashing algorithms such as Argon2, bcrypt, scrypt or PBKDF2.
- Disable legacy LM hashes and reduce reliance on NTLM.
- Enforce long passwords or passphrases.
