Cracking Password Hashes Using John the Ripper
Wait, aren't hashes uncrackable?
That's what I thought too, before this lab. The popular idea is: password goes in, hash comes out, nobody can reverse it. And technically, that's true. You cannot reverse a hash. But that's not how password cracking actually works.
Instead of reversing, attackers use candidate matching. You take a list of common passwords, hash every single one of them, and check if any of the results match the stolen hash. If they do — you have the password. It sounds almost too simple, and honestly, it is. Tools like John the Ripper (JTR) automate this at millions of comparisons per second.
So for this lab I set up a controlled experiment: generate my own hashes, try to crack them three different ways, and see what actually happens. Here's the full walkthrough.
Setting Up
I used Arch Linux for this — mainly because it's lightweight and gives you maximum CPU headroom for something this intensive. Installing JTR was one line:
sudo pacman -S john
Rather than finding hashes online and hoping they're valid, I generated all 135 of them myself using OpenSSL across 9 algorithms: MD5, MD4, SHA1, SHA224, SHA256, SHA384, SHA512, BLAKE2b512, and Whirlpool. That gave me 27 files with 5 hashes each.
I split the passwords into three categories on purpose:
| Category | Description | Examples |
|---|---|---|
| A | Common words and names | denzel, summer08 |
| B | Very short strings (1–5 chars) | ace, 123 |
| C | Name-plus-number combos | shannon21, CHAMPION |
For the wordlist I used rockyou.txt, the industry-standard list containing over 14 million real passwords from historical breaches. If your password is in there, it's toast.
The Three Attacks
Dictionary Attack
This is where you start because it's the fastest. JTR takes the wordlist, hashes every entry, and compares the results against your target hashes. That's it. If the user picked something humans commonly use, it falls almost immediately.
Every Category A password got cracked almost instantly. Words like denzel, people, and 19701970 were in rockyou.txt and matched within milliseconds. The algorithm didn't matter — weak passwords die to dictionary attacks regardless of whether they're hashed with MD5 or SHA512.
Brute-Force Attack
Brute-force doesn't use a wordlist at all. It mathematically tries every possible combination of characters — JTR calls this Incremental mode. It's guaranteed to eventually find the password, but the key word is eventually. The time scaling is kind of terrifying:
| Password Length | Crack Time |
|---|---|
| 4 characters | 0.0008 seconds |
| 6 characters | 7.3 seconds |
| 8 characters | 18.4 hours |
| 10 characters | 19 years |
| 12 characters | 171,215 years |
Passwords of 5 characters or fewer cracked within 2 minutes. Once I hit 6 characters it took 10–20 minutes and only 1 or 2 came through. Every extra character multiplies the search space massively.
Hybrid Attack
This is where JTR really shows off. Hybrid attacks combine a dictionary with transformation rules that mimic how humans actually make passwords. Nobody uses just monkey. They use Monkey2024!. The rules apply things like capitalize the first letter, append digits, replace letters with symbols, add the current year. So monkey becomes Monkey, then monkey2026, then m0nkey2026, and so on.
Passwords like shannon21, CHAMPION, and bullrider1 — things that feel "complex" — cracked easily. They follow predictable human patterns. Capitalize a name. Add a number. Done.
Results
After running all three attacks across all 27 files: 45 hashes cracked, 90 left uncracked. That's a 33% recovery rate in under an hour on a standard laptop.
One thing that genuinely surprised me: the hash algorithm barely mattered for weak passwords. Whether I hashed sun with MD5 or Whirlpool, it cracked almost immediately either way. The algorithm affected the speed of guessing — MD5 ran at over 500,000 Kc/s while Whirlpool crawled at ~2,600 Kc/s — but speed doesn't help you if the password is already in the wordlist. Strong algorithms only meaningfully protect you when the password itself is already strong.
What this actually means
Coming off my Password Strength Analyzer project, this lab hit differently. Building the analyzer taught me what makes a password theoretically strong. This lab showed me what attackers actually exploit — not entropy calculations, but human predictability.
Here's what actually works based on what I saw:
Length over complexity. A 16-character random string beats P@ssw0rd! every single time. Length pushes crack time into the centuries.
Use a password manager. The only way to get genuinely random passwords is to not let your brain generate them.
Ditch MD5 and raw SHA1 for storing passwords. Use Argon2, bcrypt, or scrypt instead — these are intentionally slow, designed to make mass cracking computationally expensive.
Always salt. A unique salt per password means two users with the same password get different hashes. It kills rainbow table attacks entirely.
Enable MFA. Even if an attacker cracks your hash, multi-factor authentication is the fail-safe for when everything else goes wrong.
The 33% recovery rate in under an hour wasn't done with specialized hardware — just a laptop and an open-source tool anyone can install. The weakest link is almost always the password itself.