Rainbow Tables (Cracking Password Hashes)

Rainbow Table Attacks

Rainbow tables are a time-memory trade-off technique used to crack password hashes. Instead of brute-forcing each password guess and hashing it on the fly (time-intensive), you precompute a massive lookup table mapping hashes back to their plaintext inputs (storage-intensive). Rainbow tables sit in the middle — compressing the chain so you trade some CPU time for significantly less disk space.

How They Work

The core idea is hash chains with reduction functions:

1. Start with a random plaintext (e.g., aaaaaa)

2. Hash it → get a hash value

3. Apply a reduction function to turn the hash back into a plausible plaintext (e.g., xk3pq9)

4. Hash that result → new hash

5. Reduce again → new plaintext

Repeat this thousands of times, forming a chain. You only store the start and end of each chain. When you want to crack a hash, you apply the reduction function to the target hash, then hash and reduce repeatedly, checking if any value matches a stored endpoint. If it does, you regenerate the chain from its start to find the plaintext that produces your target hash.

Why They Matter (And Why They're Not Enough Anymore)

Rainbow tables were devastating against unsalted hashes like raw MD5, NTLM, and SHA-1. Attacks like Pass-the-Hash in Windows environments relied on cracking NTLM hashes, and rainbow tables made that trivial for weak passwords.

But here's the thing — salting effectively kills rainbow tables. A random salt appended to each password means the attacker would need a separate rainbow table for every possible salt value, which is computationally and physically infeasible. This is why modern password storage uses:

• bcrypt / scrypt / Argon2 — Designed to be slow and memory-hard

• Per-user random salts — Each hash requires its own table

• Key stretching — Thousands of iterations per hash

Practical Use

Tools like RainbowCrack (rtgen, rtsort, rcrack) and Ophcrack were the go-to for NTLM/LM hash cracking. Precomputed tables like the "free rainbow tables" project distributed massive datasets (hundreds of GB to TB) covering common character sets.

Where They Still Apply

Rainbow tables are mostly obsolete for modern, properly-salted hashes. They're still relevant in specific scenarios:

• Unsalted NTLM hashes from older Windows systems or LSASS dumps

• Raw SHA-1/MD5 found in legacy applications

• Password-protected ZIP/RAR/PDF files (many implementations don't salt)

• IoT devices and embedded systems that still use unsalted MD5

Defensive Takeaway

If you're hardening a system: always salt, always use a memory-hard algorithm, and never roll your own crypto. If you're on the offensive side: check whether the target is using unsalted hashes, and if so, rainbow tables can save you significant GPU time versus brute force. When salts are present, switch to wordlist + rules attacks with hashcat or John the Ripper.