Password Cracking 101 — Hashes, Salts & Rainbow Tables
How attackers crack password hashes using dictionary attacks, rainbow tables, and GPU brute force — and why bcrypt, Argon2, and proper salting stop them.
When a database is breached, attackers rarely get plaintext passwords — they get hashes. The next step is cracking those hashes: finding the original password that produces each hash. Understanding how cracking works is essential for defenders choosing password storage schemes and for security auditors assessing password policies.
This guide covers the four main cracking techniques — dictionary attacks, rule-based attacks, rainbow tables, and brute force — and explains why modern password hashing functions (bcrypt, Argon2) are specifically designed to defeat each one.
The four main cracking techniques
The attacker hashes every word in a wordlist (rockyou.txt has 14 million entries) and compares each hash to the target. If the password is a common word, name, or phrase, it will be cracked in seconds.
Defense: Enforce minimum length (12+ characters) and reject passwords found in common wordlists. A password not in any wordlist cannot be cracked by a dictionary attack.
Extends dictionary attacks with transformation rules: capitalize first letter, append numbers (password1, password123), substitute letters (p@ssw0rd), add common suffixes (!). Hashcat has thousands of built-in rules. 'Password1!' is cracked in milliseconds.
Defense: Reject passwords that are dictionary words with common substitutions. Require a mix of character types only if combined with length requirements — complexity rules alone are ineffective against rule-based attacks.
A rainbow table is a precomputed lookup table mapping hashes to passwords. An attacker can crack any unsalted MD5 or SHA-1 hash in the table in milliseconds — no computation required at crack time. Tables for MD5 and SHA-1 covering all 8-character alphanumeric passwords are freely available.
Defense: A unique random salt per password makes rainbow tables useless — the attacker would need a separate table for every possible salt value. All modern password hashing functions (bcrypt, Argon2, scrypt) include salting automatically.
A modern GPU can compute 10+ billion MD5 hashes per second. An 8-character password using only lowercase letters has 26^8 = 208 billion combinations — crackable in ~20 seconds. SHA-256 is similarly fast. This is why fast hash functions are catastrophically wrong for passwords.
Defense: bcrypt at cost factor 12 limits an attacker to ~100 hashes/second per GPU. Argon2id with 64MB memory and 3 iterations limits to ~10 hashes/second. An 8-character password that takes 20 seconds to brute force with MD5 would take 60+ years with Argon2id.
Choosing the right password hashing function
Winner of the Password Hashing Competition (2015). Memory-hard (requires large amounts of RAM, defeating GPU attacks) and side-channel resistant. Parameters: memory=64MB, iterations=3, parallelism=4. Increase memory as hardware improves.
Designed in 1999, still secure. Cost factor is configurable — increase it as hardware improves. Cost 12 is a reasonable current default (takes ~250ms on a modern server). Maximum password length is 72 bytes — passwords longer than 72 bytes are silently truncated.
Memory-hard like Argon2. Used by some cryptocurrency systems. Parameters: N=32768, r=8, p=1 is a reasonable baseline. Less widely supported in standard libraries than bcrypt or Argon2.
NIST-approved and FIPS-compliant. Not memory-hard — GPU attacks are more effective than against bcrypt or Argon2. Use 600,000+ iterations with SHA-256. Required by some compliance frameworks (FIPS 140-2).
Fast hash functions designed for integrity verification, not password storage. A GPU can compute billions per second. Even with a salt, an attacker can brute-force an 8-character password in minutes. Never use these for passwords.
How salting works
A salt is a random value (typically 16-32 bytes) generated uniquely for each user. It's concatenated with the password before hashing: hash(salt + password). The salt is stored alongside the hash in the database — it's not secret.
Salting defeats rainbow tables because the attacker would need a separate table for every possible salt value. With a 16-byte random salt, there are 2^128 possible salts — precomputing tables for all of them is impossible.
Salting also ensures that two users with the same password have different hashes. Without salting, an attacker who cracks one hash immediately knows the password for every user with the same hash.
Modern password hashing functions (bcrypt, Argon2) generate and store the salt automatically as part of the hash output. You don't need to manage salts separately — the full hash string (e.g., $2b$12$...) contains the algorithm, cost factor, salt, and hash.
Audit password strength in the Hash module
The Password Auditor tool checks passwords against common wordlists, tests for rule-based patterns, and estimates crack time for different hash algorithms. The Hash Workbench lets you generate and compare bcrypt, Argon2, and SHA-256 hashes side by side.
Open Hash & Password Module