By Arjun Kumar, Senior Trainer, Systech Group 15+ years in Network Security and Cloud Architecture · Updated November 2026.
8 min read
In short
A rainbow table attack is a password-cracking method where an attacker uses a precomputed table of password hashes to find the original password behind a stolen hash. Instead of guessing and hashing passwords one at a time, the attacker looks the stolen hash up in a table that was built in advance. It works well against unsalted hashes made with fast algorithms such as MD5, SHA-1 or NTLM. It does not work against hashes that use a unique salt and a slow, memory-hard algorithm such as Argon2id, bcrypt or scrypt.
What it needs: a stolen database of password hashes and a matching precomputed table.
What it trades: disk storage for speed. The hard work is done once, in advance, and reused.
What stops it: a unique random salt for every password, plus slow hashing such as Argon2id, bcrypt or scrypt.
Table of Contents
Introduction
Every time you log in to a website, it has to answer one question: is this the right password? A safe website never keeps your password exactly as you typed it. It keeps a scrambled version called a hash. If attackers steal those hashes, a rainbow table attack is one of the ways they try to turn them back into real passwords.
It is also one of the first password-security ideas you meet in an Ethical Hacking Course in Coimbatore or any other cybersecurity training, because it explains why modern password storage works the way it does.
The Problem: Stolen Password Databases
Passwords are valuable because people reuse them. When one website loses its database, the damage often spreads far beyond that website. To see why, start with how websites keep passwords in the first place.
Why websites store hashes, not plain passwords
A hash function takes any input and produces a fixed-length string of characters. It is built as a one-way function: easy to calculate forward, but designed to be impractical to reverse. When you create an account, the website hashes your password and stores only the result. When you log in, it hashes what you typed and compares the two values. If they match, you are in. The website never needs to know your real password.
Here is a made-up practice password to show the idea. With MD5, the password Welcome@123 always turns into cd84d683cc5612c69efe115c80d0b7dc. Same input, same hash, every single time. That predictable behaviour is useful for logins. It is also the weakness a rainbow table uses.
What happens when a database is stolen
Attackers do not always need to break the login page. A leaked backup, a misconfigured server or an SQL injection flaw can expose the entire user table. The attacker now holds hashes, not passwords, so the next step is to work backwards by guessing.
If the hashes are weak, many passwords fall quickly. And because many people reuse one password on email, shopping and banking accounts, one cracked password can open several other accounts. That is why how a website stores hashes matters as much as having a strong password.
Plaintext, Hash and Salt in Simple Words
Three terms come up in every password-storage discussion. Two more explain how modern systems fight back. The table keeps them side by side.
The stored record on a well-built website is the salt plus the hash of (salt + password). Two users who both choose Welcome@123 get two completely different hashes, because their salts are different. Hold on to that idea. It is the reason salting defeats rainbow tables.
How a Rainbow Table Attack Works
A rainbow table attack is a time-memory trade-off. The attacker spends a lot of time and disk space once, then reuses the result to crack many hashes quickly. Martin Hellman described the basic trade-off in 1980. Philippe Oechslin improved it in 2003 and gave us the rainbow table.
Step 1: Build the table in advance
Storing every possible password next to its hash would need huge amounts of disk space. Rainbow tables avoid this with chains. The attacker starts with one password, hashes it, then uses a reduction function to turn that hash into a new candidate password. Then the process repeats. A reduction function is not the reverse of hashing. It is just a rule that maps a hash back into the space of possible passwords.
Only the first password and the last hash of each chain are stored. Everything in the middle can be rebuilt when needed. A rainbow table uses a different reduction function at each step, which stops chains from merging into each other.
Here is a simplified chain. The hash values are shown as H1, H2 and H3 to keep it readable, and real chains are much longer:
sunny1 -hash-> H1 -reduce-> tiger7 -hash-> H2 -reduce-> mango3 -hash-> H3
Stored in the table: sunny1 … H3 (the middle is not stored)
Step 2: Steal the hashes
The attacker gets the hashes from somewhere, such as a leaked backup, an exposed server or an old breach dump. The hashes must match the algorithm the table was built for. A table for MD5 is useless against bcrypt.
Step 3: Look up the match
Take one stolen hash. Apply the reduction and hash steps to it until the result matches the end of a stored chain. Then rebuild that chain from its starting password and watch for the step that produces the stolen hash. The password just before it is the answer.
In the example above, if the stolen hash is H2, one reduce-and-hash step gives H3, which matches the stored end. Rebuilding the chain from sunny1 shows that tiger7 produced H2. No slow guessing was needed during the attack. The hard work was done earlier.
This only works if the hash is predictable. If every user had a different random salt, the attacker would need a separate table for every salt value. That is not practical.
Rainbow Table vs Brute Force vs Dictionary Attack
All three attacks try to find a password that matches a stolen hash. They differ in when they do the hashing work.
One point is often misunderstood. Salting stops rainbow tables, but it does not stop guessing. An attacker can still run a dictionary or brute-force attack against a salted hash. What makes that expensive is a slow, memory-hard algorithm such as Argon2id, bcrypt or scrypt. That is why good password storage needs both a salt and a slow hash.
Is a Rainbow Table Attack Still a Threat Today?
Yes, but mainly against weak or outdated password storage. A system that uses a unique salt and a modern slow hash is not exposed to this attack in a practical way. A system that still uses unsalted fast hashes is.
Where it still works: old, unsalted MD5, SHA-1 and NTLM hashes
Rainbow tables remain useful wherever hashes are fast, unsalted and predictable:
- Windows NTLM and LM hashes. Both are unsalted, and rainbow tables for NTLM are widely available. The older LM hash is even weaker because it splits the password into two halves of up to 7 characters and hashes each half separately.
- Legacy applications. Older web apps and databases that still hash passwords with plain MD5 or SHA-1, with no salt.
- Old breach dumps. Hashes leaked years ago can still be cracked if they were never salted.
A real example is the 2012 LinkedIn breach. The passwords were hashed but not salted, which made them relatively easy to crack. Roughly 6.5 million were posted online in 2012, and in 2016 a seller offered data on 167 million accounts, of which 117 million included passwords. (LinkedIn never confirmed the 2012 figure.)
Why modern systems are rarely hurt by it
Rainbow tables only cover the password lengths and character sets they were built for, and they are tied to one hash algorithm. Well-designed systems also use salts, so a table built for one hash type does not help. Attackers facing fast hashes today often use powerful graphics cards (GPUs) to try huge wordlists directly, so a rainbow table is one tool among several rather than the only one. Defending against all of them uses the same advice: a unique salt and a slow, memory-hard hash
Is a Rainbow Table Attack Still a Threat Today?
Yes, but mainly against weak or outdated password storage. A system that uses a unique salt and a modern slow hash is not exposed to this attack in a practical way. A system that still uses unsalted fast hashes is.
Where it still works: old, unsalted MD5, SHA-1 and NTLM hashes
Rainbow tables remain useful wherever hashes are fast, unsalted and predictable:
- Windows NTLM and LM hashes. Both are unsalted, and rainbow tables for NTLM are widely available. The older LM hash is even weaker because it splits the password into two halves of up to 7 characters and hashes each half separately.
- Legacy applications. Older web apps and databases that still hash passwords with plain MD5 or SHA-1, with no salt.
- Old breach dumps. Hashes leaked years ago can still be cracked if they were never salted.
A real example is the 2012 LinkedIn breach. The passwords were hashed but not salted, which made them relatively easy to crack. Roughly 6.5 million were posted online in 2012, and in 2016 a seller offered data on 167 million accounts, of which 117 million included passwords. (LinkedIn never confirmed the 2012 figure.)
Why modern systems are rarely hurt by it
Rainbow tables only cover the password lengths and character sets they were built for, and they are tied to one hash algorithm. Well-designed systems also use salts, so a table built for one hash type does not help. Attackers facing fast hashes today often use powerful graphics cards (GPUs) to try huge wordlists directly, so a rainbow table is one tool among several rather than the only one. Defending against all of them uses the same advice: a unique salt and a slow, memory-hard hash
How to Prevent Rainbow Table Attacks
Three layers work together. Each one covers a gap the others leave open.
Use a unique salt for every password
Generate a new random salt for each password and store it next to the hash. Because every salt is different, identical passwords produce different hashes, and a precomputed table becomes useless. The salt does not have to be secret. Its only job is to make every hash unique. Most modern password libraries create and store the salt for you, so you rarely handle it by hand.
Use slow, memory-hard hashing (key stretching)
Fast algorithms such as MD5, SHA-1 and plain SHA-256 were designed to be quick, which is exactly what an attacker wants. Password-hashing algorithms are designed the other way round. They repeat the work many times (key stretching) and, in the case of Argon2id and scrypt, need a lot of memory for each guess. That makes large-scale guessing expensive even when the attacker has the stolen hashes. Use a well-tested library and never write your own hashing scheme.
Add multi-factor authentication and strong password rules
Multi-factor authentication (MFA) does not stop a hash from being cracked. What it does is limit the damage: a cracked password alone is not enough to log in. Pair it with sensible password rules. Current NIST guidance favours longer passwords and checking new passwords against lists of known-breached ones over forcing odd symbol rules. For users, a password manager with a long, unique password for every site closes the reuse problem.
Which Password Hashing Algorithm Should You Use?
For a new system, choose Argon2id. If it is not available, scrypt or bcrypt are the usual fallbacks, and PBKDF2 is used where a standard such as FIPS-140 requires it. Avoid MD5, SHA-1 and plain SHA-256 for passwords. The settings below are the minimums from the OWASP Password Storage Cheat Sheet at the time of writing. Always benchmark on your own server and check the current guidance before you deploy.
Password storage on Cisco switches and routers
Network devices have the same problem. A switch stores the passwords for its admin accounts, and those need protecting too. Cisco IOS uses numbered password types, and they are not equal:
enable algorithm-type scrypt secret <your-password>
username admin algorithm-type scrypt secret <your-password>
Use secret, not password, and confirm the exact command on your IOS version. If you are learning to configure Cisco switches, for example in a CCNA Course in Trichy, build this habit from the very first lab.
Include image: a screenshot of a Cisco switch running-config showing an enable secret 9 line with its 9 hash.
Safe Hands-On Lab: See How a Salt Changes a Hash
You can see the whole idea in about two minutes. This lab uses Python on your own computer and a made-up practice password. It does not crack anything. Use it only with practice passwords, never with a real one, and only on your own machine.
Video spot: if you record a lab demo, embed it here.
Step 1: Save and run this script
Save the code as salt_lab.py and run python3 salt_lab.py.
import hashlib
import os
password = b“Welcome@123” # a made-up practice password
# 1. Plain hashes (no salt): same input always gives the same output
print(“MD5 :”, hashlib.md5(password).hexdigest())
print(“SHA-256 :”, hashlib.sha256(password).hexdigest())
# 2. Add a random salt: the output changes every time
for i in range(2):
salt = os.urandom(16)
salted = hashlib.sha256(salt + password).hexdigest()
print(f”Salt {i+1} :”, salt.hex(), “->”, salted)
# 3. A slow, memory-hard hash (scrypt) with a random salt
salt = os.urandom(16)
slow = hashlib.scrypt(password, salt=salt, n=2**14, r=8, p=1)
print(“scrypt :”, slow.hex())
Step 2: Read the output
- The MD5 and SHA-256 lines are the same on every run: cd84d683cc5612c69efe115c80d0b7dc and c75f28325cfa028ea13872f977a29e0e87c99a4f390fe260f24d7e1f05fb8d75. A rainbow table could contain these.
- The two salted lines are different from each other and change on every run, even though the password is identical. A table built in advance cannot contain them.
- The scrypt line is also unique per salt, and it took noticeably more work to compute.
Step 3: Try one experiment
In the scrypt line, change n=2**14 to n=2**16 and add maxmem=128 * 1024 * 1024 inside the brackets. Python limits scrypt memory by default, and this setting raises that limit. Run the script again. Scrypt now uses more memory and takes longer. That extra cost is exactly what slows down an attacker making millions of guesses. The lab settings are for learning. For a real application, use a maintained Argon2id library and follow OWASP’s current settings.
Include image: a screenshot of the terminal output with the two identical lines and the two different salted lines highlighted.
Labs like this are the hands-on side of password security. If you want guided practice with a trainer, a Cyber Security Course in Chennai is a natural next step after your first lab.
Not sure which route fits you?
Tell us your stream and what you are hoping for, and we will tell you honestly which option suits.
Get course detailsHow to Check If Your Website Is at Risk
You do not need special tools for a first check. You need to know what your system does with passwords. Only inspect systems you own or have written permission to review.
Find where passwords are hashed: Look in your framework, CMS or login code for the function or library that creates the hash. If you cannot find one, passwords may be stored in plain text, which is worse than any weak hash.
Look at what is stored: The format of a stored value gives a useful clue:
Length is only a clue: A value of the right length may be salted or unsalted, so confirm in the code. Check whether each user row has its own random salt.
Check old accounts and imported data: Legacy tables, old backups and data migrated from a previous system often still hold weak hashes.
Upgrade without forcing a reset: OWASP suggests rehashing passwords at each user’s next successful login, and expiring the old hashes of users who do not return.
Turn on MFA: for admin, email and other high-value accounts.
Do not forget network devices: Check switch and router configurations for Cisco type 0 or type 7 passwords.
For current recommended settings, keep the OWASP Password Storage Cheat Sheet open while you plan the change, because algorithm settings are adjusted as hardware improves.
Learn Cybersecurity and Ethical Hacking at Systech
Understanding rainbow tables is a good first step. The next step is learning how attacks and defences work across a whole network, with a trainer and real labs, so you can apply the ideas at work.
Systech Group offers Ethical Hacking, Cyber Security and CCNA networking training in Coimbatore, Chennai and Trichy. The ethical hacking syllabus lists topics that connect directly to this article: cryptography and PKI, footprinting, password cracking, web application attacks including the OWASP Top 10, sniffing and spoofing, and cloud and mobile security. Systech’s CCNA page also mentions practical labs on Cisco routers and switches, which matters because network devices store passwords too.
A sensible way to choose:
This is a suggestion, not a rule. Many learners start with networking and then add security. Contact your nearest Systech branch for current batch dates, classroom or online options, and fees.
Frequently asked questions
Can a rainbow table crack a password that has a unique salt?
Not in practice. A rainbow table is built for one exact hash calculation. If every password has its own random salt, the attacker would need a separate table for every salt, which is not realistic. The attacker can still guess passwords one at a time against a single salted hash, so a slow hashing algorithm is needed as well.
Are rainbow table attacks still used, or have GPUs made them outdated?
They are still relevant against unsalted legacy hashes such as NTLM, MD5 and SHA-1. Graphics cards let attackers test very large wordlists against fast hashes directly, so rainbow tables are one tool among several. Neither approach works well against salted hashes made with a slow, memory-hard algorithm.
How can I tell if my website's password hashes are open to a rainbow table attack?
Look at the stored values. A 32-character or 40-character hexadecimal value with no separate salt suggests unsalted MD5 or SHA-1. Values starting with 2b point to bcrypt, and argon2id points to Argon2id. This is only a clue, so confirm how hashing is done in the code.
Is SHA-256 with a salt safe enough for storing passwords?
It is better than no salt, but it is still not recommended. SHA-256 is fast, so an attacker can make many guesses per second against each stolen hash. OWASP lists fast hashes such as SHA-256 as unsuitable for password storage. Use Argon2id, scrypt, bcrypt or PBKDF2 with a high iteration count instead.
Should I choose Argon2id or bcrypt for a new project?
Choose Argon2id if your language and framework support it. OWASP names it as the preferred option because it is memory-hard. bcrypt is still widely supported, but OWASP positions it for legacy systems, and it only reads the first 72 bytes of a password in most implementations. If you already use bcrypt with a suitable work factor, you can plan a move to Argon2id rather than treat it as an emergency.
Our old application uses MD5. How can we upgrade without forcing every user to reset a password?
Does a salt have to be kept secret?
No. A salt is stored next to the hash, and many hash formats embed it in the same string. Its job is to make every hash unique, not to hide anything. Some systems add a separate secret value called a pepper, stored outside the database, as an extra layer. It supports the salt and does not replace it.
Does multi-factor authentication stop a rainbow table attack?
No. MFA does not stop hashes from being cracked. It limits the damage, because a cracked password alone is not enough to log in. Use it for admin and email accounts, and still fix weak password storage.
Is the password on my Cisco switch protected from a rainbow table attack?
It depends on the password type. Type 7 is a reversible cipher, not a hash, so anyone who can read the configuration can decode it without any table. Type 5 is salted MD5, which is better but dated. Types 8 (PBKDF2 with SHA-256) and 9 (scrypt) are the stronger choices. Check your show running-config output for 8 or 9.
How can a beginner practise password security and cracking legally?
Only on systems you own or have written permission to test. Using made-up passwords in your own lab, like the Python script above, is the safest start. Testing someone else’s system without permission can be a crime under laws such as India’s Information Technology Act. A structured course gives you guided labs and clear rules about what is allowed, which is why Systech’s Ethical Hacking and Cyber Security courses in Coimbatore, Chennai and Trichy are a practical way to build these skills.
Final Thoughts
A rainbow table attack is simple at heart: do the hard work once, then look up many hashes quickly. It only succeeds when hashes are predictable. Two habits remove most of the risk: a unique salt for every password, and a slow, memory-hard algorithm such as Argon2id.
If you run a website or a network, check how your passwords are stored this week and plan the upgrade at the next login. If you are learning, run the lab above, then build on it with guided training. To go from understanding one attack to working confidently in security, talk to Systech about Ethical Hacking and Cyber Security courses in Coimbatore, Chennai or Trichy.