Two tools, and the question that actually decides between them

Hashcat and John the Ripper both crack password hashes, both are free, and both are on every serious tester's machine. The lazy framing is "Hashcat is the GPU one, John is the CPU one" — true as far as it goes, and useless when you are staring at a hash file deciding what to run. The question that decides it is simpler: do you already know what the hash is, and is it a common format? If yes, Hashcat's speed wins. If no — an odd format, a file John recognises and you don't, a box with no GPU — John's versatility wins. Most professionals keep both for exactly this reason, and this guide is about knowing which to reach for when.

Where the speed difference comes from — and where it evaporates

Hashcat is built to run on the GPU, and on fast hash types the gap over CPU cracking is enormous — a good graphics card computes MD5 or NTLM guesses hundreds of times faster than a CPU can. Published benchmarks put a high-end GPU in the hundreds of billions of NTLM guesses per second; a CPU is in the low billions at best. For a large list of fast hashes, that ratio is the difference between an afternoon and a month.

But the gap is a property of the hash type, not the tools, and it collapses on slow hashes:

bcrypt is the honest example. Its whole purpose is to resist fast guessing, and it resists a GPU nearly as well as a CPU — so Hashcat's headline advantage nearly vanishes, and the two tools finish a bcrypt job in the same order of magnitude of time. Treat any single benchmark number as an order-of-magnitude guide, not a spec: it shifts with the GPU, the driver, the hashcat version and the exact hash. Run hashcat -b on your own hardware for a figure you can trust.

The real lesson is not "Hashcat is 200× faster". It is that the algorithm decides whether speed even matters — and when the target uses bcrypt, your choice of tool matters far less than your choice of wordlist and rules.

What each tool is actually better at

Hashcat's strengths are raw throughput on common hashes and a mask-attack engine that is a pleasure to use once ?l?u?d?s is muscle memory. If you have a GPU, a large list of a known common hash type, and want maximum speed, this is the tool.

John the Ripper's strengths are the ones that show up when the situation is awkward:

• It identifies hashes for you. Point John at a file and it will often just recognise the format and start, where Hashcat needs the correct -m first. On an unfamiliar hash, John is the faster path to a running crack.
• It handles exotic formats. The 2john helper family — zip2john, ssh2john, keepass2john, pdf2john and dozens more — extracts a crackable hash from an encrypted archive, an SSH key, a password manager database or a PDF. This is often the only* practical way to get at those, and it is John's territory.
• "Single crack" mode uses the account's own metadata — username, full name, GECOS fields — as candidate passwords, which catches the person who set their password to a variation of their own name. Nothing in Hashcat does this as naturally.
• It needs no GPU. On a server, a VM, or any box without a graphics card, John just works.

Side by side

Hashcat: NTLM list, dictionary + the best64 rules. The bread-and-butter run.
hashcat -m 1000 -a 0 hashes.txt rockyou.txt -r rules/best64.rule
Hashcat: a shaped brute force for 8-char "Aaaaa11!" passwords.
hashcat -m 0 -a 3 hashes.txt ?u?l?l?l?l?d?d?s
John: crack a Linux shadow file, letting it detect the format.
john --wordlist=rockyou.txt --rules /etc/shadow
John: turn an encrypted ZIP into a hash, then crack it — the thing Hashcat can't do alone.
zip2john secret.zip > zip.hash
john --wordlist=rockyou.txt zip.hash

That last pair is the clearest illustration of the split: Hashcat has no equivalent of zip2john, so even a die-hard Hashcat user reaches for John to extract the hash — and may then feed it back to Hashcat to crack it fast. The tools are complementary far more than they are rivals.

A workflow that uses both

• Identify. If you don't know the format, let John try first, or run hashcat --identify.
• Extract, if needed. Encrypted archive, SSH key, PDF, KeePass? That is a *2john job.
• Crack fast, if it's a common hash and you have a GPU. Hand the hash to Hashcat with a dictionary and best64.
• Fall back to John for anything exotic, or when there is no GPU to be had.
• Spend effort on guesses, not tools. On a slow hash, neither tool will brute-force its way through — a good wordlist and rule set is what cracks it, in either tool.

The rule that applies to both

Cracking a hash you were not authorised in writing to test is unlawful, and the plaintexts you recover — in any tool — are among the most sensitive data an engagement produces. Report the findings, store the results encrypted, and delete them when the work is done. Practise on your own hashes, deliberately vulnerable VMs, or sanctioned CTF material until the workflow above is second nature.

Running either without local setup

Both tools install cleanly, and Hashcat in particular rewards real GPU hardware you control. If you would rather not provision a cracking box, CyberSec Pro runs Hashcat from a browser — hashes and options on a form, the command shown before it runs, output streamed back, the job isolated in its own container and the hashes treated as the sensitive material they are. For the format-extraction and detection work, John on a local machine remains the natural companion. The decision is unchanged either way: known common hash and speed matters, reach for Hashcat; unknown or exotic format, reach for John; and when it's bcrypt, stop worrying about the tool and improve your wordlist.