Key Insights
According to the 2025 Data Breach Investigations Report, Verizon found that 54% of ransomware victims in 2024 had their domains appear in credential dumps circulating on the open web, and 40% had corporate email addresses included in those compromised credentials. Many of those dumps contain password hashes rather than plaintext, and when storage is weak, cracking them is a well-understood problem.
A rainbow table attack is one of the oldest techniques for that work. It compares stolen hashes against a precomputed table of hash-to-password mappings so cracking becomes a lookup instead of fresh guessing each time.
This guide explains how a rainbow table attack works and the storage conditions that make it succeed. It covers the mechanics of hash chains, compares rainbow tables to brute force, dictionary, and GPU-accelerated cracking, and lays out the layered defenses that keep stolen hashes from becoming working credentials.
Key Takeaways
Rainbow tables use precomputed hash chains and reduction functions to crack passwords from stolen hashes, reducing storage needs while speeding up lookups.
The technique works best against unsalted fast hashes such as MD5, SHA-1, and NTLM, which is why legacy Windows authentication and older web password stores remain the main targets.
Salting removes the shared lookup advantage that makes rainbow tables efficient. Memory-hard hashing such as Argon2id separately addresses GPU-accelerated offline cracking.
Modern password storage pairs per-password metadata, secret peppers held outside the database, and rehash-on-login to upgrade storage without mass resets.
A layered defense combining salts, stronger hashing, increasing work factors, and multi-factor authentication reduces both legacy and modern password risks.
What Is a Rainbow Table Attack?
A rainbow table attack cracks passwords by comparing stolen hashes against a precomputed table of hash-to-password mappings built with chained hash and reduction functions.
Precomputation Turns Hash Cracking Into a Lookup Problem
A rainbow table sidesteps the one-way property of cryptographic hash functions through precomputation: an attacker spends time upfront building a large table of passwords and their hashes, then cracks stolen hashes through lookup rather than fresh guessing.
A full table storing every possible password-hash pair would require enormous storage, so rainbow tables compress the data using hash chains and store only chain endpoints. That design is what separates a rainbow table from a simple hash dictionary.
The tradeoff is some lookup simplicity for far less storage, and the attacker can reuse the same table against every stolen hash from systems that share the same unsalted algorithm.
Offline Hash Theft Removes Application-Layer Defenses
Offline hash theft bypasses application-layer controls entirely: once an attacker obtains a hash dump, they can test password candidates outside the target application, with no rate limiting, account lockout, or detection to slow them down, and can keep testing over time because a single breach can expose many credentials at once.
Attackers obtain these hash dumps through breaches, phishing attack campaigns, or infostealer malware infections, and prior-breach data can later resurface on the dark web. A cracked hash from an old breach becomes a working credential wherever the user reused the same password. When that reused credential turns up as a login, Abnormal is designed to help security teams spot it, flagging sign-ins from unfamiliar devices, locations, or behavior patterns before the account sees further misuse.
Unsalted Fast Hashes Make One Table Reusable Across Accounts
Rainbow tables work best when fast hash algorithms such as MD5, SHA-1, and NTLM are used without a salt, since identical passwords then produce identical hashes across accounts, letting one precomputed table work across an entire database.
If two users pick the same password and the system stores it as unsalted MD5, both accounts hash identically, so a single lookup cracks both; a unique salt per password removes that shared value and makes each hash different.
How a Rainbow Table Attack Works
A rainbow table attack precomputes alternating hash and reduction chains, storing only the endpoints to compress many hash-password pairs into one table.
Hellman's Time-Memory Tradeoff Trades Storage for Computation
Martin Hellman published a method that sits between brute-force password attacks and full precomputation. The approach alternates between the hash function and a reduction function, which maps a hash output back into the password space as a valid candidate. The reduction function simply turns the digest into another possible password value so the chain can continue, without inverting the hash itself.
Starting from one password, the chain alternately hashes and reduces for a set number of steps, and the table stores only its starting point and final endpoint. Chain merging is the main weakness in Hellman's original approach: different chains can collide and follow the same path, reducing useful coverage.
Per-Column Reduction Functions Reduce Chain Merging
Rainbow tables cut down on chain merging by assigning a distinct reduction function to each column position instead of reusing the same one at every step.
Philippe Oechslin described this structural change and named the result "rainbow chains," unlike the usual approach of assigning a different color to each reduction function across the table's columns. Two chains fully merge only when a collision occurs at the same position in both. This structure makes rainbow tables a more practical form of the original time-memory tradeoff and improves their performance against deterministic hashes such as Windows LAN Manager (LM) hashes.
The Lookup Process Works Backward From the Target Hash
Rainbow-table lookup works backward through possible chain positions until the attacker finds a stored endpoint. The attacker applies the last reduction function to the target hash and checks whether the result matches an endpoint. If it does not, the attacker repeats the process for earlier positions, testing whether the target hash could have appeared somewhere inside an existing chain.
Finding a matching endpoint lets the attacker regenerate that chain forward from its start until a plaintext's hash matches the target; that plaintext is the password.
Where a Rainbow Table Attack Still Matters Today
Rainbow table attacks remain relevant against legacy systems that use unsalted fast hashes. Proper salting and modern password hashing have reduced their value against current storage implementations.
Proper Salting Eliminates the Precomputation Advantage
Proper salting makes reusable rainbow-table precomputation impractical, because each account's unique password-salt pair stops identical passwords from producing the same stored hash across users.
An attacker would need separate precomputed material for each unique salt, which pushes the attack back toward per-guess computation against individual accounts.
Legacy NTLM Hashes Keep Rainbow Tables Relevant
Legacy NTLM hashes keep rainbow tables relevant because they preserve the deterministic storage model that the attack exploits. Microsoft's deprecated Windows features list marks LANMAN, NTLMv1, and NTLMv2 as deprecated, removes NTLMv1 starting in Windows 11 24H2 and Windows Server 2025, and recommends Negotiate (which tries Kerberos first) in place of hard-coded NTLM calls, still a major blocker to retirement.
The gap between deprecation and removal leaves a practical window open: an attacker who obtains NTLM hashes faces the same deterministic storage older web applications used, where one password produces one hash across every account, so a single table can serve the whole directory. Closing that window starts with an inventory of remaining NTLM dependencies (see the FAQ below).
GPU Cracking Replaces Rainbow Tables Against Salted Hashes
GPU-accelerated cracking is the primary offline threat against properly salted targets: unlike static rainbow tables, GPU-based tools incorporate per-user salts into each candidate hash on the fly, so a salted MD5 or SHA-1 store that resists precomputation stays exposed to high-speed dictionary password attacks and brute-force attacks.
Salting removes rainbow tables' shared precomputation advantage; memory-hard algorithms such as Argon2id instead make each guess consume meaningful memory, limiting large-scale parallel guessing on GPU hardware.
Rainbow Table Attack Examples and Conditions
Rainbow table attacks require stolen password stores with deterministic unsalted hashes. Plaintext and encrypted storage create different failure modes.
Unsalted MD5 and SHA-1 Stores Remain the Primary Target
Unsalted fast hashes give attackers the reusable input rainbow tables need. LinkedIn's breach is a well-known example: the company stored passwords as unsalted SHA-1, and after part of the dataset circulated initially, the full set surfaced online later, giving crackers a second opportunity against the same hashes. Unsalted MD5 stores carry the same weakness.
Plaintext and Encrypted Storage Are Different Failure Modes
Plaintext and reversibly encrypted password stores create serious credential exposure, but they do not create rainbow table attacks: plaintext storage requires no cryptographic reversal, and symmetric password encryption is a different failure mode again, since it relies on a reversible operation rather than a one-way hash function.
Plaintext stores leave no cracking step between the attacker and the credential. Reversibly encrypted stores instead depend on protecting the encryption key.
How to Prevent a Rainbow Table Attack
Preventing a rainbow table attack requires layered password storage: per-user salts remove precomputation value, stronger hashing raises the cost of offline cracking, and operational controls reduce the impact of a compromised credential.
Per-User Salting Breaks Precomputation
Per-user salts, generated randomly and stored alongside the hash, are the direct countermeasure: they make identical passwords produce different hashes. NIST SP 800-63B Revision 4 requires salting and hashing with a scheme resistant to offline attacks, with each salt containing at least 32 bits to minimize collisions.
Peppering Adds a Defense-in-Depth Layer
Peppering strengthens password storage by adding a secret input the system keeps outside the password database, so an attacker who steals the hashes still lacks one input needed to verify guesses the way the server does.
NIST recommends an additional keyed hash or encryption operation using a secret key known only to the verifier, generated with an approved random bit generator and ideally held in a hardware-protected area such as a hardware security module (HSM) or trusted execution environment (TEE). The OWASP Password Storage Cheat Sheet treats the pepper as a shared secret rather than a per-password value, applied before hashing or afterward as a hash-based message authentication code (HMAC); a compromised pepper requires affected users to reset their passwords.
Peppering supplements salting by separating part of the password-verification process from the credential store, which makes it a defense-in-depth security measure rather than the primary control.
Memory-Hard Hashing Algorithms Raise the Cost of Cracking
Memory-hard algorithms such as Argon2id and scrypt raise the cost of the GPU-accelerated brute force that remains after salting, by forcing each hash to consume significant RAM and limiting GPU parallelism.
OWASP ranks password-hashing options by context:
Argon2id: the preferred choice, with memory and iteration settings configured for the target system.
Scrypt: the fallback when Argon2id is unavailable.
Bcrypt: reserved for legacy systems.
PBKDF2: recommended for environments that require FIPS-140 compliance.
NIST does not mandate a specific algorithm in this area, so teams can use OWASP for concrete parameters.
Fast algorithms such as SHA-256 still permit high-throughput guessing even after systems add salts, because they consume little memory and complete quickly.
Tuned Work Factors and Rehashing Upgrade Storage Over Time
Teams can regularly tune work factors and rehash passwords after successful authentication, upgrading storage without a disruptive mass reset. Parameters set years ago may no longer protect against today's computing power, so NIST recommends storing a reference to the hashing scheme and cost factor with each password (the PHC string format, below) so teams can migrate to stronger settings.
OWASP describes an ordered migration path:
After a user authenticates successfully, the system verifies the submitted password against the old hash and then rehashes it with the current algorithm and parameters.
For users who haven't logged in, the system can wrap the legacy hash inside the stronger algorithm (bcrypt(md5($password)), for example), though OWASP warns layered hashes can be easier to crack, so a direct hash should replace them at the next login.
For accounts that never return, the organization can expire the old hashes and require a reset.
This staged process moves active users to stronger storage and places a clear expiration path on dormant legacy hashes.
MFA and Account Monitoring Complement Storage Controls
Multi-factor authentication and account monitoring reduce the impact of a recovered or reused password: strong password storage protects an organization's own database, but it can't stop someone from reusing a password exposed by another service. Multi-factor authentication controls and breach monitoring therefore remain useful companion measures. NIST also requires verifiers to check each new or changed password in full against a blocklist of common, expected, or compromised values, including corpuses from past breaches and context-specific strings such as the service name or username.
Monitoring matters because attackers may reuse a cracked password elsewhere. The first visible sign can be a sign-in to a cloud email security account from an unfamiliar context, followed by messages that do not fit the user's usual patterns. Security teams can use Abnormal's account takeover protection to help surface login anomalies, behavioral shifts, and unusual communication patterns in Microsoft 365 and Google Workspace environments.
Rainbow Table Attack vs. Other Password Attack Methods
Rainbow tables occupy a specific niche among password attacks: they trade upfront computation and storage for reusable lookups against deterministic hashes.
Rainbow Tables vs. Brute Force and Dictionary Attacks
Rainbow tables, brute force, and dictionary attacks differ in when they compute candidates, how much precomputed storage they require, and how salting affects them.
Method | Computation and Storage | Effect of Salting |
|---|---|---|
Rainbow tables | Attackers precompute hash chains, store only the endpoints, and rely on fast lookups. | Salting makes reusable tables impractical because each unique salt requires separate precomputed material. |
Brute-force password attacks | Attackers compute candidate hashes at runtime, which requires more processing but minimal precomputed storage. | Brute force remains viable because a cracking tool can add the known salt to each candidate during testing. |
Dictionary password attacks | Attackers use curated wordlists and common mutations instead of exhaustive enumeration. | Dictionary guessing remains practical against each password-salt pair, often with GPU acceleration. |
Rainbow tables retain an advantage only where unsalted hashing still exists.
Rainbow Tables vs. Credential Stuffing and GPU-Accelerated Cracking
Credential stuffing and GPU cracking both operate differently from rainbow tables. Credential stuffing attacks use stolen plaintext username-password pairs from earlier breaches to attempt logins elsewhere. No hash reversal occurs, and salting offers no defense. The attack avoids the target's password store entirely and exploits reuse instead, since people often leave identical or similar passwords on other sites after a breach, so one exposed credential creates risk across services.
GPU-accelerated cracking takes a different path. It runs live hash computation across large parallel workloads and can adapt to salts, varied algorithms, and custom rules in ways static rainbow tables cannot. For modern systems, GPU-based guessing represents the dominant offline threat. Rainbow tables remain relevant mainly in legacy environments.
Close Legacy Hash Gaps With Layered Password Defenses
Organizations can contain rainbow table risk by identifying deterministic legacy hashes and migrating them to salted, memory-hard password storage. Per-user salting removes the precomputation advantage, and stronger password hashing separately raises the cost of offline guessing.
The remaining exposure concentrates in legacy web stores that never migrated and in NTLM-dependent Windows environments where unsalted hashes persist. Tuned work factors, peppers, multi-factor authentication, and credential-stuffing monitoring limit the impact when attackers recover or reuse a password, and password storage stays effective when organizations keep updating algorithms and parameters as attack methods change.
The hardest moment to catch is when a cracked or reused credential finally gets used, since the login itself looks legitimate. Abnormal's account takeover protection applies behavioral AI to that moment, correlating session and device signals with each user's normal patterns to help surface sign-ins from unfamiliar contexts and the unusual activity that often follows. Paired with identity threat protection, it extends that visibility across Microsoft 365 and Google Workspace so a stolen hash from an old breach is less likely to translate into a working foothold.
Explore the Abnormal platform to see how behavioral detection complements your existing password-storage and identity controls.
Frequently Asked Questions
What Specific Argon2id Configuration Parameters Does OWASP Recommend for Password Hashing, and How Should Teams Tune Them for Their Environment?
OWASP's current baseline for Argon2id is a minimum memory cost of 19 MiB (19,456 KiB), two iterations, and one degree of parallelism. Teams should tune these by measuring hash time on production hardware, targeting roughly 500 milliseconds per login, raising memory cost rather than cutting it on higher-traffic systems, and reviewing parameters annually as GPU performance and memory bandwidth improve.
How Can Organizations Identify and Inventory All Remaining NTLM Dependencies in Their Windows Environment Before Microsoft Disables NTLM by Default?
Organizations can map NTLM usage with Windows Event logging on domain controllers and member servers (Event IDs 8001 to 8004, plus 4776 for credential validation) and the Restrict NTLM auditing policy, which logs attempts without blocking them. Microsoft Defender for Identity and Netlogon logging extend that visibility to service accounts that authenticate silently with hard-coded NTLM calls. A few business cycles of data let teams classify high-volume sources and prioritize privileged accounts and internet-facing services for remediation.