Rainbow table attacks expose why password hashing needs salts

At a glance

What this is: This is an explainer on rainbow table attacks and the key finding is that salting plus slow password hashing defeats precomputation.

Why it matters: It matters because IAM teams still own password storage, authentication design, and credential lifecycle decisions that determine whether hashes can be cracked at scale.

👉 Read WorkOS's explainer on rainbow table attacks and password hashing

Context

Rainbow table attacks exploit a gap in password storage design, not a weakness in authentication alone. The issue is that unsalted or weakly protected password hashes can be matched through precomputation, which makes hash storage a security boundary that IAM teams have to design deliberately.

For modern identity programmes, this sits squarely at the intersection of human authentication, credential storage, and lifecycle controls. Once password hashes are treated as durable assets rather than disposable implementation detail, the need for unique salts, slow hashing, and legacy hash removal becomes a governance issue, not just a crypto choice.

Key questions

Q: How should security teams prevent rainbow table attacks on password hashes?

A: Use a modern password hashing algorithm such as Argon2id or bcrypt, generate a unique random salt for every password, and tune the work factor so hashing is intentionally slow. This combination removes the precomputation advantage that rainbow tables rely on and makes offline cracking materially more expensive.

Q: Why do unsalted password hashes remain risky even when the hash function is strong?

A: A strong hash function does not stop precomputation if every user shares the same input pattern. Without salts, attackers can build one reusable table and apply it across many targets, which makes weak passwords and legacy stores crackable far faster than brute force alone.

Q: What breaks when organisations use fast general-purpose hashes for password storage?

A: Fast hashes such as SHA-256 make offline guessing cheap because attackers can test huge numbers of candidates per second. That is acceptable for integrity checks, but it is a weak design for password storage because the attacker controls the pace once the database is exposed.

Q: How do teams know whether password hashing is actually strong enough?

A: Check three things: every password has a unique salt, the hash algorithm is password-specific, and the verification cost is high enough to slow attackers without harming users. If any of those is missing, the system still leaves room for efficient offline cracking.

Technical breakdown

How rainbow table precomputation works

Rainbow tables trade storage for speed by precomputing chains of hashes and reductions. A reduction function maps a hash back into a candidate password space, and the attacker stores only the chain endpoints instead of every intermediate value. That makes lookups far faster than brute force when the target uses a known, unsalted hash algorithm. The attack depends on reusing the same precomputed table across many targets, which is why it was so effective against legacy systems with weak password storage.

Practical implication: remove any password storage design that still allows a reusable precomputed table to apply.

Why salts break the attack model

A salt is a unique random value added to each password before hashing. The same password therefore produces a different hash for every user, which destroys the attacker’s ability to reuse one rainbow table across accounts. The salt does not need to stay secret, but it does need to be unique and unpredictable. Without that uniqueness, the database still exposes passwords to cheap precomputation and duplicate-password detection.

Practical implication: enforce per-password unique salts as a baseline control in every authentication system.

Why fast hashes still fail modern password security

Fast general-purpose hashes such as SHA-256 are designed for integrity and speed, not password protection. They can be computed so quickly that brute-force cracking remains practical once an attacker has hashes. Modern password hashing algorithms slow the process down and add memory cost, which raises the attacker’s economics even after salting has removed precomputation. This is why bcrypt, scrypt, and Argon2 are treated as password-specific controls rather than generic hashing choices.

Practical implication: use password hashing algorithms that are intentionally slow and memory-hard, not general-purpose digest functions.

Breaches seen in the wild

• Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Rainbow table resistance is a password storage design problem, not an authentication feature. The article shows that the attack succeeds when teams store reusable hashes without uniqueness or cost controls. That means the security boundary sits in how passwords are transformed and stored, not in the login prompt itself. Practitioners should treat password hashing as a control surface that needs explicit governance, not a background implementation detail.

Unique salts are the point where password hashes stop being reusable attacker assets. A salt makes the same password produce a different hash per account, which breaks the assumption that one precomputed table can crack many users. This is a simple technical change, but it changes the economics of compromise in a way that legacy hash storage cannot recover from. The implication is that any identity programme still relying on shared or predictable hash inputs has already accepted unnecessary exposure.

Slow, memory-hard hashing is now the real baseline for human identity protection. The article’s comparison of SHA-256 with bcrypt and Argon2 makes the operational trade-off clear: speed is the attacker’s advantage, not the defender’s. For IAM teams, password storage must be evaluated as part of human identity governance, because authentication resilience depends on how the credential is protected after creation. The implication is that legacy password hashing is a lifecycle risk, not just a crypto debt.

Legacy hash formats create a hidden recertification problem for identity platforms. Unsalted MD5 and SHA-1 hashes can linger in older applications long after the systems around them have been modernised. That creates a mismatch between current governance expectations and historical storage choices. Practitioners should see this as a control drift issue across the identity lifecycle, where the assurance model has moved on but the stored credential has not.

Password cracking pressure remains relevant wherever old authentication estates survive. The article is right to note that rainbow tables are obsolete in well-designed systems, but obsolescence is not the same as irrelevance. Older platforms, embedded apps, and migrated directories still expose organisations to the same attack economics. Teams should therefore prioritise removal of reusable password-hash assumptions wherever human identity is still supported by inherited infrastructure.

From our research:

• 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to Astrix Security & CSA.
• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%.
• For a deeper lifecycle lens, The 52 NHI breaches Report shows how exposure patterns persist when credentials outlive their intended use.

What this signals

Password hashing is one of those controls that looks solved until a legacy estate proves otherwise. Teams that still carry old authentication code paths need a hard inventory of hash formats, salt handling, and rehash opportunities, because the attack surface is determined by what remains in production, not by what the standard recommends in theory.

Hash reuse debt: when a password hash can be attacked the same way across many accounts or systems, the organisation has converted a credential into reusable attacker material. The practical signal is simple: if migration work does not remove the old hash, the risk has not been remediated.

If your programme already tracks identity and credential lifecycle changes, the next step is to connect password policy to platform retirement. The most persistent exposure often sits in migrated apps, inherited directories, and service workflows that keep old password stores alive long after the main identity stack has modernised.

For practitioners

• Inventory legacy password hashing schemes Identify every application and directory that still stores unsalted MD5, SHA-1, or similarly fast password hashes. Prioritise systems that can be queried offline if the database is exposed.
• Standardise on per-password unique salts Verify that every password hashing path generates a cryptographically random salt per credential and stores it with the hash. Make the control mandatory in new builds and migration work.
• Move to slow, memory-hard password hashing Use Argon2id where supported, or bcrypt where platform constraints require it, and tune the work factor so a verification takes roughly 100 milliseconds on production hardware.
• Retire reusable hash assumptions in migration plans Treat password hash migration as a lifecycle remediation project, not a cosmetic refactor. Rehash credentials during reset or login flows so legacy values do not persist indefinitely.

Key takeaways

• Rainbow table attacks are a legacy password cracking method that still matter wherever weak hash storage survives.
• Unique salts and slow, memory-hard password hashing are the controls that eliminate the attacker's precomputation advantage.
• Identity teams should treat password hashing quality as a governance issue across the credential lifecycle, not as a one-time implementation choice.

Key terms

• Rainbow Table: A rainbow table is a precomputed set of hash chains used to reverse weak password hashes faster than brute force. It only works when the same hash output can be reused across many targets, which is why salts and password-specific hashing algorithms neutralise it so effectively.
• Salt: A salt is a unique random value added to a password before hashing so the same password produces a different hash for each account. In identity systems, salts are not secrets, but they are essential because they break attacker precomputation and stop duplicate passwords from looking identical in storage.
• Memory-Hard Hashing: Memory-hard hashing is a password protection approach that requires substantial memory as well as compute, making large-scale cracking more expensive on GPUs and specialised hardware. It matters because password storage must resist offline attacks after a database breach, not just normal login traffic.
• Work Factor: A work factor is the configurable cost applied to password hashing so verification takes longer for attackers but remains acceptable for users. In practice, the right work factor is high enough to slow bulk guessing and low enough to avoid making sign-in unusable or unreliable.

Deepen your knowledge

Rainbow table attacks and password hashing hardening are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are modernising authentication and credential storage in a legacy environment, it is worth exploring.

This post draws on content published by WorkOS: Rainbow table attacks: What they are and how to prevent them. Read the original.