🔓 Password Attacks & Hashing
How attackers crack passwords — and why the vulnerability is always in the password⏱ ~2 min
When you shred a document, you can't un-shred it. A cryptographic hash is similar: you put a password in, get a fixed-length string out, and it's computationally infeasible to reverse. When you log in, the system hashes your input and compares it to the stored hash — it never stores or compares your actual password. The problem: if your password is weak, attackers can hash candidate passwords and compare until they find a match. The vulnerability is always the password choice, not the hashing itself.
Password Attack Types — The Full Taxonomy
| Attack | How It Works | Exploits This Vulnerability | Stopped By |
|---|---|---|---|
| Dictionary Attack | Try every word in a list of common passwords, known passwords, and variations | User chose a common or predictable password | Long, random passphrases; rate limiting; account lockout |
| Brute Force | Try every possible combination of characters systematically | Short password length — combinations are small enough to enumerate | Password length; account lockout; slow hash algorithms (bcrypt) |
| Credential Stuffing | Use username/password pairs from previous breaches on other services | Password reuse across multiple accounts | Unique password per service (password manager); MFA |
| Password Spraying | Try a small set of common passwords (e.g., 'Password1!') against many accounts | Common weak passwords; avoids per-account lockout thresholds | Ban common passwords; MFA |
| Rainbow Table Attack | Precomputed table mapping common passwords to their hashes; fast lookup | Weak/common password stored with no salt | Password salting (random value added before hashing) |
| Offline Cracking | Steal the hash database; crack offline with unlimited attempts (no lockout) | Short or common passwords; unsalted hashes | Slow hash algorithms; salting; MFA so cracked passwords still don't work |
The Role of Hashing in Password Storage
Password databases should never store plaintext passwords — if the database is breached, all passwords are immediately compromised. Instead, the system stores the hash. When you log in, your input is hashed and compared. Good hash algorithms for passwords: bcrypt, Argon2, scrypt. Bad: MD5, SHA-1 (too fast — allows billions of guesses per second on modern hardware).
Password Vulnerability Scenarios
| Password | Vulnerable To | Why |
|---|---|---|
| password | Dictionary attack | Literally the most common password — every dictionary list starts here |
| p@ssw0rd | Dictionary attack | Known substitution pattern; all major wordlists include common substitutions |
| abc123 | Brute force + dictionary | Short, sequential; in every list; brute-forced in seconds |
| Jennifer1987! | Dictionary + pattern attack | Name + birth year + symbol — very common structure even if personalized |
| correct-horse-battery-staple | None practical | 4 random common words = 44+ bits of entropy; brute-forcing in years |
| Xk9#mP2@qL7!nB4 | None practical | 15 random characters = enormous entropy; decades to brute-force even offline |
Online vs Offline Attacks — A Critical Distinction
- •Attacker interacts with the real login interface
- •Account lockout applies after N failures
- •Rate limiting slows attempts to 1-2/second
- •IP blocking stops high-volume attacks
- •Easy to detect and block with basic controls
- •Even weak passwords are partially protected
- •Attacker has a copy of the password hash database
- •No lockout — unlimited attempts on local hardware
- •GPU clusters: billions of MD5 hashes per second
- •A 6-character password cracked in seconds
- •No detection — all activity is local
- •Only defense: strong passwords + slow hash algorithms
A company stores all employee passwords hashed with MD5 (no salt). An attacker breaches the database and steals 50,000 password hashes. They run the hashes through a rainbow table lookup. Within an hour, 35,000 (70%) of the passwords are cracked. Why specifically did the rainbow table work so effectively, and what two changes would have prevented this?