Password Cracking: How It Actually Works (Beginner to Advanced)

Most people picture password cracking as a hacker typing guesses into a login box while a progress bar fills. That is not what this is. Real password cracking happens offline, against a stolen database of hashes, on hardware the target never sees. There is no lockout, no rate limit, no failed-login alert. It is a pure maths race: how many candidate passwords can I hash per second, and how many do I have to try before one of them matches. Everything that matters in this field, the tools, the wordlists, the attack modes, the choice of GPU, flows from that one question.

TL;DR

Password cracking is the offline process of recovering a plaintext password from its hash. You cannot reverse a hash, so you guess: hash a candidate, compare, repeat, billions of times a second on a GPU. The workflow is always the same five steps: capture the hash, identify what algorithm produced it, choose an attack (dictionary, rules, mask, hybrid, combinator), optimise for the hardware, and recover the plaintext. The single biggest variable is the hash itself: a fast unsalted hash like MD5 or NTLM falls in seconds, while a deliberately slow hash like bcrypt, Argon2, or sha512crypt can be computationally hopeless against a strong password. The two tools worth learning are hashcat (GPU, fastest) and John the Ripper (CPU-strong, unmatched file-format coverage). This guide is the map; every section links to the deep dive.

What password cracking actually is

A modern application never stores your password. It stores a hash: the output of a one-way function that turns correcthorse into something like 9b8b63.... When you log in, the server hashes what you typed and compares it to the stored hash. Same input, same hash; the server never needs the original.

Hashing is one-way by design. There is no unhash(). So when an attacker steals a hash table, usually through SQL injection, a backup leak, or a compromised box, they cannot simply decrypt it. What they can do is run the same one-way function forward, over and over, on guesses:

candidate "password"  -> md5 -> 5f4dcc3b5aa765d61d8327deb882cf99   no match
candidate "123456"    -> md5 -> e10adc3949ba59abbe56e057f20f883e   no match
candidate "hunter2"    -> md5 -> 2ab96390c7dbe3439de74d0c9b0b1767  match -> recovered

That is the entire game. The reason it works at all is that humans pick predictable passwords and that some hash algorithms are fast enough to try billions of guesses per second. The reason it sometimes fails is that good algorithms are deliberately slow and good passwords have too much entropy to guess in any reasonable time. The space between those two facts is this whole discipline.

Hashing is not encryption. Encryption is reversible with a key; hashing is not reversible at all. If a site can email you your existing password, it stored it reversibly, and that is a finding, not a feature. For the storage side of this, see what column type a password should be.

The workflow every crack follows

Whether you are recovering one forgotten archive password or working a red-team engagement with a million NTLM hashes, the shape is identical.

1. Capture. Get the hash into a file. From a database dump, a Windows SAM/NTDS.dit, a Linux /etc/shadow, a captured Wi-Fi handshake, or an encrypted file you extract a hash from with a *2john tool.
2. Identify. Work out which algorithm produced it so you can tell the cracker the right mode. A $2b$ prefix is bcrypt; a 32-character hex string is probably MD5 or NTLM; $6$ is sha512crypt. See how to identify a hash type.
3. Choose an attack. Match the attack mode to what you know about the password and how slow the hash is. This is the judgement call that separates fast results from wasted GPU-weeks. See the attack types and when to use each.
4. Optimise. Pick the workload profile, optimised kernels, and the order you run attacks in so you spend cycles where they pay off. See speeding up hashcat.
5. Recover. Read the cracked plaintext out of the potfile (--show), report, and remediate.

Most beginners skip straight to step 3 with a brute force and wonder why it never finishes. The experienced answer is that steps 2 and 3 are where the win is, and step 3 is rarely brute force.

The attack types, and when to reach for each

hashcat exposes the attack types as numbered modes (-a 0/1/3/6/7/9). The names matter less than knowing which problem each one solves.

The decision tree I actually run: dictionary, then dictionary plus rules, then hybrid, then targeted masks, and only then unconstrained brute force, and against a slow hash I often stop after rules because exhaustive masks are hopeless. The full reasoning, with the keyspace maths, is in dictionary vs brute force vs mask vs hybrid.

Pure brute force has a branding problem: it sounds powerful and is usually the worst choice. A mask is "smart" brute force, you constrain the search to plausible shapes, but even a constrained eight-character full-keyspace mask is 95^8 candidates, and against anything slower than a fast hash that is years. Wordlists and rules win because real passwords are not random.

Not all hashes are equal: the fast/slow divide

This is the single most important concept in the field, and the one beginners miss. The algorithm the password was stored with decides whether cracking is trivial or effectively impossible. There are two camps.

Fast hashes were designed for speed (verifying file integrity, indexing). Using them for passwords is a mistake, but a common one. A GPU chews through billions per second.

Slow hashes were designed for passwords, deliberately made expensive through a configurable work factor so that a defender's one-login-per-user cost is trivial but an attacker's billions-of-guesses cost is ruinous.

Here is the divide in orders of magnitude, on a single modern GPU (an RTX 4090, approximate hashcat benchmark figures; see the GPU benchmark deep dive for full numbers):

Look at the gap. NTLM is roughly ten million times faster to attack than bcrypt. That single ratio is why a leaked NTLM dump is a five-minute job and a leaked bcrypt table is mostly uncrackable. It is also why every storage guide on this site, bcrypt in MySQL, Argon2 in MySQL, the right password column type, pushes you onto a slow algorithm. You are not making the password un-stealable; you are making the stolen hash worthless.

The tools: hashcat and John the Ripper

Two tools cover almost everything. They overlap but have different sweet spots, and the head-to-head comparison goes deeper.

• hashcat is the GPU king. It is the fastest cracker in existence for the vast majority of modes, with the richest attack-mode and rules engine. If you have a GPU, this is your primary tool. The hashcat cheat sheet is the fill-in-your-values command reference.
• John the Ripper (the "jumbo" build) is CPU-strong, runs anywhere, and has unmatched coverage of file formats. Its *2john helpers extract crackable hashes from ZIP, RAR, PDF, and Office files, KeePass databases, SSH keys, and more. The John cheat sheet covers its pipeline.

A practical split: hashcat for raw database hashes and Wi-Fi, John for "I have an encrypted file and need the password out of it."

Wordlists: your most valuable asset

A cracker is only as good as the candidates it tries, and the candidate list that matters most is the wordlist. The famous rockyou.txt (14 million real passwords from a 2009 breach) still cracks a shocking fraction of any modern dump, because people keep choosing the same passwords. Beyond it sit curated collections (SecLists, weakpass), breach-derived lists, and target-specific lists you generate yourself.

The skill is not hoarding gigabytes of wordlists; it is ordering and shaping them, running the highest-yield lists first, mutating them with rules, and building custom lists from the target's own language. The full treatment, including where to get them and how to generate your own, is in password cracking wordlists.

How long will it actually take?

The honest answer is "it depends entirely on the hash and the password," but here is the intuition.

Against a fast hash, the password's strength is what saves it, and usually it does not. An eight-character lowercase password is 26^8, about 200 billion candidates, which a single RTX 4090 grinds through against NTLM in around a second. Add character classes and length and the number explodes, but most leaked fast hashes fall not to brute force but to a wordlist plus rules in minutes, because the passwords were never random.

Against a slow hash, the algorithm is what saves the password. At a few tens of thousands of guesses per second, that same 200-billion-candidate space is centuries. This is why, against bcrypt or Argon2, you do not brute force at all. You run a high-quality wordlist and good rules, you crack the weak passwords, and you accept that the strong ones are out of reach. That is not failure; that is the algorithm doing its job.

From beginner to master: a path

If you are starting out, here is the order I would learn this in:

1. Understand hashing (this page) and identify a hash on sight.
2. Run your first crack with hashcat against an MD5 you generated yourself.
3. Master the dictionary + rules combo, the rules engine is where most real cracks come from.
4. Learn masks for the cases where you know the password's shape: the mask attack.
5. Pick the right attack for the job: internalise when to use which mode.
6. Go after real targets: NTLM, bcrypt, WPA2 Wi-Fi, encrypted files.
7. Optimise: tune hashcat and learn to read benchmarks so you spend cycles where they pay.

Keep both cheat sheets (hashcat, John) open while you work. Nobody memorises mode numbers.

The defender's view (why any of this matters)

I do not write this so people can crack other people's passwords. I write it because you cannot defend against an attack you do not understand. Everything above is also the argument for how to store passwords:

• Use a slow, salted, modern algorithm: bcrypt at a sane cost, or Argon2id. The storage guides cover the exact column types and parameters: bcrypt in MySQL, Argon2 in MySQL, bcrypt in PostgreSQL.
• Never store a fast hash (MD5, SHA-1, SHA-256, NTLM) for a password. If your database holds one of those, treat it as already cracked.
• Salt every hash so attackers cannot use precomputed rainbow tables or attack the whole table at once.
• Push users toward length over complexity (a strength check helps), because length is what defeats masks.

When you have watched rockyou.txt empty half a leaked table in ninety seconds, you stop arguing about password policy. You just move everything to Argon2id.

Where to go next

This is the hub. The deep dives:

• Tools: how to use hashcat · John the Ripper · hashcat vs John
• References: hashcat cheat sheet · John cheat sheet · identify a hash
• Method: attack types · mask attack · rules · wordlists · optimisation
• Targets: MD5 · NTLM · bcrypt · WPA2 · ZIP/RAR/PDF