Rainbow table attacks explained: how salted hashing stops password crackers
A modern GPU running Hashcat can test 100 billion MD5 hash guesses per second. Rainbow tables let attackers skip most of that computation entirely, looking up results from a precomputed table rather than brute-forcing them live. The defence, a technique called salting, makes those tables worthless at zero extra cost to the user.
What is a rainbow table attack? A rainbow table attack is a method of cracking password hashes by looking up precomputed hash-to-password mappings in a large reference table rather than computing each hash from scratch. When an attacker steals a database that stores unsalted password hashes, a rainbow table can recover the original password in milliseconds. Salting each password with a unique random value before hashing makes precomputed tables computationally useless.
How password hashing works
Properly built services never store your password in plain text. Instead, when you create an account and set a password, the system runs that password through a one-way mathematical function called a hash function. The output, the hash, is a fixed-length string of characters. It is stored in the database instead of the original password.
When you log in, the system hashes the password you entered and compares the result to the stored hash. If they match, you are authenticated. The original password is never stored or compared directly.
This approach protects users if the database is stolen. An attacker gets a list of hashes, not passwords. To get passwords out, they have to either guess inputs until one produces a matching hash, or use a shortcut: rainbow tables.
Not all hash functions are equal. MD5 and SHA-1 are general-purpose hash functions built for speed, which makes them terrible for passwords. bcrypt, Argon2, and scrypt are purpose-built password hashing functions designed to be slow and memory-intensive, making large-scale cracking expensive. OWASP's Password Storage Cheat Sheet (2026) recommends Argon2id as the first choice for new applications, with bcrypt as an acceptable alternative for legacy codebases.
How rainbow tables work
Brute-force hash cracking is simple in concept: generate a candidate password, compute its hash, compare to the target. At 100 billion MD5 hashes per second on a high-end GPU, an eight-character lowercase password can be cracked in under a minute. But cracking longer or more complex passwords that way still takes significant compute time and electricity.
Rainbow tables solve this with a time-memory trade-off, first described by cryptographer Philippe Oechslin in his 2003 paper "Making a Faster Cryptanalytic Time-Memory Trade-Off." Instead of computing hashes on the fly, an attacker precomputes millions or billions of hash-to-password pairs and stores them in a highly compressed lookup table. Cracking a stolen hash then becomes a table lookup: find the hash in the table, read off the corresponding password. The computation happened once, offline, before the attack started.
The "rainbow" structure refers to the compression technique Oechslin used. Rather than storing every hash-password pair individually (which would require terabytes), the table stores reduction chains: sequences of hash-reduce operations that let a compact structure cover a large fraction of the search space. A practical MD5 rainbow table covering all printable ASCII passwords up to eight characters fits in roughly 460 GB, a one-time investment that works against any database using unsalted MD5 hashes.
Several precomputed tables are publicly available. CrackStation distributes a 15 GB table of 1.5 billion password-hash pairs collected from prior breach datasets, covering common passwords across multiple hash functions.
Why salting defeats rainbow tables
A salt is a random value, at least 16 bytes of cryptographically random data, generated uniquely for each user account. Before the password is hashed, the salt is combined with it. The result is hashed, and both the hash and the salt are stored in the database.
This one step makes every stored hash unique, even if two users pick the same password. "password123" hashed with one salt produces a completely different result than "password123" hashed with a different salt. A precomputed rainbow table is built against a specific, known input structure. Salting changes the effective input for every account, so the attacker would need to build a new rainbow table from scratch for every unique salt. With 16 bytes of random salt, there are 2^128 possible salt values, a number large enough to make that approach infeasible.
According to NIST Special Publication 800-63B, password verifiers must use a salt of at least 32 bits, randomly generated using an approved random bit generator, before applying the chosen hashing function. Most modern implementations use 128-bit or larger salts.
The salt does not need to be secret. It is stored next to the hash in plaintext. Its only job is to ensure that two identical passwords produce two different hashes in the database. Keeping the salt secret is not part of the defence model.
What attackers do instead
Salting killed rainbow tables as a practical attack vector against well-configured systems. But cracking salted hashes is still possible if the underlying hashing algorithm is fast. This is where the choice of algorithm matters.
Against a database using salted MD5, an attacker with an eight-GPU cracking rig can still test roughly 100 billion per-account guesses per second. Common passwords, "password", "123456", "qwerty", and tens of thousands of variations, fall in seconds even with a unique salt. bcrypt slows this to roughly 20,000 guesses per second per account. Argon2id, configured to use 64 MB of memory and four iterations, drops it further still.
Three attack methods remain viable against salted-but-fast-hashed databases:
- Dictionary attacks: testing a list of known passwords and common variations against each hash. The Rockyou2024 dataset, 10 billion passwords compiled from prior breaches, is the most widely used starting point. A password that appears in this dataset falls regardless of salting if the hash function is fast.
- Rule-based attacks: applying transformation rules to a dictionary, such as appending years, substituting letters for numbers, or capitalising the first letter. These cover the vast majority of passwords that deviate slightly from a simple word.
- Mask attacks: brute-forcing all combinations matching a specific pattern. A mask like "upper-lower-lower-lower-lower-digit-digit-symbol" covers a predictable fraction of "strong-looking" user-chosen passwords efficiently.
None of these attacks work against a long, randomly generated password. A 20-character random credential from a cryptographically secure generator is outside the reach of dictionary and rule attacks by definition, and the search space for mask attacks is too large to exhaust before the hardware cost exceeds any realistic attacker budget.
Password hashing algorithm comparison
The algorithm a service uses determines how much protection you get from a salted but leaked database. You have no control over what the service chooses, but knowing the landscape helps you understand your exposure after a breach notification.
| Algorithm | Designed for passwords | Memory-hard | Approx. GPU guesses/sec (single hash) | OWASP 2026 status |
|---|---|---|---|---|
| MD5 | No | No | 100 billion+ | Avoid |
| SHA-1 | No | No | 30 billion+ | Avoid |
| SHA-256 | No | No | 10 billion+ | Avoid for passwords |
| bcrypt (cost=12) | Yes | No | ~20,000 | Acceptable |
| PBKDF2-SHA256 (600,000 iter) | Yes | No | ~100,000 | Acceptable (FIPS contexts) |
| scrypt (N=32768) | Yes | Yes | ~10,000 | Recommended |
| Argon2id (m=64MB, t=4) | Yes | Yes | ~1,000 | First choice |
GPU guesses-per-second figures are approximate benchmarks for a single high-end consumer GPU (RTX 4090) against a single hash with a unique salt. A professional cracking rig with eight GPUs multiplies these by eight.
How to protect yourself
The choice of hashing algorithm is made by the service, not the user. But two things are entirely within your control: the strength of the password you set, and what happens if a database gets stolen.
Use a randomly generated password for every account. Dictionary attacks and rule-based attacks are the methods that succeed against salted databases using fast algorithms. Both depend on your password being predictable. A 20-character random string from this site's password generator is not in any word list, cannot be covered by rule transformations, and sits in a search space that no attacker will exhaust with brute force.
Use a different password on every account. The purpose of salting is to prevent a single cracked hash from giving access to other accounts. If you reuse the same password, that protection disappears. The cracked hash from one database becomes the key to your other accounts. A password manager handles unique credentials at scale. NordPass stores unique passwords for every account and flags any stored credentials that appear in known breach databases, which is the fastest way to know when a service you use has been exposed.
Check breach databases after a notification. Not all services tell you when they have been breached. HaveIBeenPwned tracks over 14 billion compromised accounts across hundreds of known incidents. Checking your email address there costs nothing and takes 10 seconds. If your address appears in a breach, rotate the relevant password immediately, whether or not you receive a formal notification from the company.
Enable multi-factor authentication wherever possible. Even if an attacker successfully cracks a password from a stolen hash, MFA stops them at the login page. A cracked password is not useful if authentication requires a second factor the attacker does not have.
Why long random passwords specifically matter here: According to OWASP's Password Storage Cheat Sheet, the primary defence against cracking after a database breach is the unpredictability of the password itself. Salting and a slow algorithm raise the cost. A randomly generated password of 20+ characters eliminates the attack entirely, because neither dictionary-based nor mask-based cracking can reach it in any practical timeframe regardless of the algorithm the service used.
Frequently asked questions
Can rainbow table attacks still work in 2026?
Against unsalted databases, yes. Older forums, small web applications, and some legacy enterprise systems still store passwords using unsalted MD5 or SHA-1. When those databases leak, any password in the breach can be cracked instantly with publicly available tables. Against properly salted databases using Argon2id or bcrypt, rainbow tables are useless. The attack surface is not zero, but a well-implemented modern application is not vulnerable to this specific technique.
If salting defeats rainbow tables, why do breached passwords still get cracked?
Because most successful post-breach cracking is not rainbow table cracking. It is GPU-accelerated dictionary and rule-based cracking against fast hash functions like MD5 or SHA-256. The distinction matters: salting solved the rainbow table problem specifically, not the broader problem of predictable passwords combined with fast hashing. A salted MD5 hash of "Summer2024!" will be cracked in under a second because dictionary+rule attacks do not need a precomputed table.
Does a password manager protect against rainbow table attacks?
Indirectly, yes. A password manager ensures that every account gets a unique randomly generated credential. Random credentials are not in any dictionary, not in any precomputed table, and not reachable by rule-based attacks regardless of the hashing algorithm a site uses. The protection comes from the randomness of the password, not the manager itself. The manager makes it practical to maintain that randomness across dozens of accounts.
What should I do if a site I use was breached and used MD5 hashes?
Change the password on that site immediately. Then change it on every other site where you used the same password. A salted MD5 hash of a weak or common password can be cracked within hours of a breach going public. Assuming the password is compromised the moment you receive the notification and acting on that assumption is the safest approach. Use the password generator to produce a replacement and store it in a password manager so you do not need to remember it.
How do I know what hashing algorithm a site uses?
Most sites do not publish this information. Security-focused transparency reports from larger companies sometimes disclose it. After a breach, third-party researchers and news coverage often reveal the storage method. The practical takeaway is that you cannot verify a site's implementation before an incident. Treating every stored password as potentially weak, by using unique randomly generated credentials across all accounts, removes your dependency on any single site's security decisions.