You have probably read that websites store your password as a "hash" rather than the real thing. So how do attackers who steal those hashes turn them back into passwords? One of the oldest and cleverest answers is the rainbow table - and understanding it also explains why one small technique, salting, quietly defeats it.
What a rainbow table is
When you create an account, a good website does not store your actual password. It stores a hash: the output of a one-way function that scrambles the password into a fixed string, in a way that cannot simply be reversed. If someone steals the database, they get the hashes, not the passwords - and they still have to work out which password produced each hash.
A rainbow table is a way to do that fast. It is a massive, precomputed lookup that links hashes back to the passwords that made them. The attacker does the expensive hashing work in advance, stores it compactly, and then just looks up each stolen hash. That is the whole idea: spend storage now to save time later.
How the attack works
Cracking a hash by brute force means hashing every possible guess live until one matches - correct, but slow at scale. Rainbow tables speed this up with a clever storage trick. Rather than saving every hash, they build long chains of alternating hashing and "reduction" steps and store only the start and end of each chain. That keeps an otherwise impossibly large table small enough to be useful. To crack a stolen hash, the attacker rebuilds the relevant chain and recovers the original password.
Why salting defeats them
Here is the important part, and the good news. A rainbow table only works if a given password always produces the same hash. The defence is a salt: a unique, random value added to each password before it is hashed. With per-user salts, two people with the identical password end up with completely different hashes, and a precomputed table is worthless - the attacker would need a separate rainbow table for every possible salt, which is not practical.
Modern systems go further, pairing salts with deliberately slow hash functions such as bcrypt, scrypt or Argon2. Slow hashing makes even live guessing expensive, and salting kills the precomputation shortcut. Together they make rainbow tables a mostly historical threat - dangerous against old or badly-built systems that store unsalted hashes, but neutralised by anyone doing password storage correctly today.
How it compares to other attacks
It helps to place rainbow tables next to the attacks they are often confused with:
- Brute force hashes every possible combination live until one matches - slow, defeated by long passwords. See what a brute-force attack is.
- Dictionary attack tries a list of likely passwords instead of all combinations - faster, defeated by not using common or reused passwords.
- Credential stuffing replays real leaked username and password pairs - defeated by unique passwords. See what credential stuffing is.
- Rainbow table precomputes the hashing work and looks it up - defeated specifically by salting.
What it means for you
You cannot control how a website stores its hashes, and reputable sites already salt and slow-hash, which stops rainbow tables cold. What you can control is the one thing that limits the damage when a site gets it wrong: a unique, long password on every account. If one site stores hashes badly and its passwords are cracked, a password you used nowhere else exposes nothing beyond that single account. A password manager makes generating and storing those unique passwords effortless, which is the practical takeaway behind every one of these attacks.
★ Audit Cure53 2024 · ✓ Plan gratuit · Cross-platform
Lock down your accounts → NordPassStrong unique passwords · breach scanner · free tier→Frequently asked questions
What is a rainbow table?
A rainbow table is a large, precomputed table that maps password hashes back to the passwords that produced them. Websites store passwords as hashes rather than plain text, so an attacker who steals the hash database still has to work out the original passwords. Instead of hashing every guess on the spot, a rainbow table does that work in advance and stores the results in a compact form, so the attacker can look up a stolen hash and find the matching password quickly. It is a classic time-for-memory trade: huge storage up front in exchange for fast cracking later.
How does a rainbow table attack work?
Passwords are usually stored as hashes - one-way scrambles that cannot simply be reversed. To crack them, an attacker needs to find which input produces a given hash. Computing that live for billions of guesses is slow, so rainbow tables precompute long chains of hash-and-reduce steps and store only the endpoints, which keeps the table small enough to be practical. Given a stolen hash, the attacker rebuilds the relevant chain to recover the original password. The catch is that this only works against hashes that were not individually salted.
How do you defend against rainbow tables?
With a salt. A salt is a unique, random value added to each password before it is hashed, so two users with the same password get completely different hashes. Because a rainbow table is precomputed for unsalted inputs, a per-user salt makes it useless - an attacker would need a separate table for every possible salt, which is not feasible. Modern password storage combines per-user salts with deliberately slow hash functions like bcrypt, scrypt or Argon2, which together make rainbow tables a largely historical threat rather than a current one.
Rainbow table vs brute force vs dictionary attack - what's the difference?
All three try to recover passwords from hashes, but differently. A brute-force attack computes the hash of every possible combination live until one matches - thorough but slow. A dictionary attack tries a list of likely passwords (common words and leaked passwords) rather than every combination. A rainbow table precomputes the hashing work in advance and looks answers up, trading storage for speed. Salting defeats rainbow tables specifically, because it breaks the assumption that the same password always hashes to the same value.
Should I still worry about rainbow tables?
For your own accounts, indirectly. You cannot control how a website stores its hashes, and well-run sites already salt and use slow hashes, which neutralises rainbow tables. What you can control is using a unique, long password on every site, so that even if one site stores hashes badly and gets cracked, the exposed password does not unlock anything else. A password manager makes that practical.
