Home › Resources › Rainbow Tables

Executive Summary

A rainbow table is a precomputed structure that reverses password hashes back into the original passwords very quickly by trading large amounts of storage for cracking speed. It works only against hashes made without a unique salt. Adding a random salt to each password makes precomputation useless, which is why salting is a foundational rule of safe password storage.

What It Is

A rainbow table is a compact, precomputed reference that maps hash values back to the passwords that produced them. Rather than cracking each stolen hash from scratch, an attacker who has a rainbow table for a given hashing algorithm can look up many hashes almost instantly. The table is built ahead of time through a clever chaining technique that stores far less than a full list of every hash while still covering an enormous number of candidates. This is a time and memory tradeoff. The huge upfront cost of building the table pays off by making later lookups extremely fast, but the whole approach collapses if each password was hashed with a unique salt.

Why It Matters

Rainbow tables illustrate why how you store passwords matters as much as how strong they are. A perfectly reasonable password becomes trivially crackable if the system stored it as an unsalted hash with a common fast algorithm, because a matching rainbow table may already exist. This is a storage side failure that no user can fix. The defense, salting, is simple and well established, which is why unsalted password storage is considered a serious flaw. For a professional, rainbow tables make the case for salting and slow hashing concrete, and they are a classic topic in secure development, auditing, and certification exams.

How It Works

A hash function turns a password into a fixed length value that cannot be reversed directly. Rainbow tables get around this by precomputing chains of alternating hashing and reduction steps, storing only the start and end of each chain. To crack a hash, the attacker regenerates chains until the target hash falls into one, then walks that chain to recover the password. The result is fast lookup with manageable storage. The countermeasure is a salt, a unique random value added to each password before hashing. Because every user's salt is different, an attacker would need a separate table for every salt, which is computationally hopeless. Modern slow, salted hashing functions defeat rainbow tables entirely.

Architecture Diagram

Visual Workflow

Common Attacks

• Reversing unsalted hashes stolen from a breached database
• Cracking legacy password stores that used fast, unsalted algorithms
• Using widely available precomputed tables for common hash functions
• Recovering passwords from old backups that kept unsalted hashes
• Chaining recovered passwords into credential stuffing on other sites

Common Mistakes

• Storing passwords as unsalted hashes of any kind
• Using a single shared salt for all users instead of a unique one each
• Relying on a fast general purpose hash rather than a slow password hash
• Assuming an obscure algorithm is safe without salting
• Keeping old unsalted hashes in backups and forgotten systems

Best Practices

• Always add a unique random salt to every password before hashing
• Use a slow, memory hard, purpose built password hashing function
• Never use fast general purpose hashes for storing passwords
• Migrate legacy unsalted hashes to modern salted storage on next login
• Protect and rotate backups so old unsalted hashes are not left exposed
• Layer MFA so a recovered password alone is not enough

Quick Checklist

• Every password stored with a unique per user salt
• Slow, memory hard password hashing function in use
• No fast general purpose hashes used for passwords
• Legacy unsalted hashes identified and migrated
• Backups reviewed for old unsalted password stores
• MFA enforced to reduce impact of any recovered password

Recommended Tools

Industry Standards

Career Relevance

Rainbow tables are a staple topic for secure developers, security engineers, and penetration testers who assess how an application stores passwords. GRC analysts check storage practices against frameworks during audits, and SOC and incident responders understand the risk when a hash database is stolen. Being able to explain why salting defeats precomputation, and why slow hashing matters, is a classic and frequently tested skill for the roles AI-Governance-Jobs.com serves.

Interview Questions

• What is a rainbow table, and what tradeoff makes it work?
• Why does adding a unique salt to each password defeat rainbow tables?
• Why is a fast general purpose hash a poor choice for password storage?
• How would you migrate a legacy unsalted hash store safely?
• Why are slow, memory hard hashing functions preferred for passwords?

Related Certifications

Further Reading

• OWASP Password Storage Cheat Sheet
• NIST SP 800-63B Digital Identity Guidelines
• NIST SP 800-132: Password Based Key Derivation

FAQ