When people picture a hacker cracking a password, they imagine someone typing frantically at a terminal, running mysterious software until an alarm goes off. The reality is considerably less dramatic — and considerably more effective.

Password cracking is largely automated, runs at scale, and exploits the fact that human password choices are predictable. Understanding the mechanics makes it obvious what actually protects you and what doesn't.

Step One: Getting a Database to Crack

Almost all serious password cracking happens offline, not against a live login form. Why? Because login forms rate-limit attempts, trigger alerts, and lock accounts. Attacking them directly is slow and obvious.

The starting point is a breached database — a user table extracted from a compromised service. These databases contain usernames, email addresses, and password hashes. Once an attacker has a copy of the database, they can run billions of guesses per second against it without anyone noticing, without rate limits, and without the risk of being blocked.

This is why the type of hashing algorithm a service uses matters enormously to you, even though you have no control over it.

Hashing: The Security You're Relying On

Services don't store your actual password — they store a hash. When you log in, they hash what you type and compare the result. If it matches, you're in. The idea is that the hash function is one-way: you can't reverse it to get the original password.

In practice, the protection depends entirely on which hashing algorithm is used.

MD5 and SHA-1 — once commonly used, now considered inadequate for passwords. They're fast, which was the point for general-purpose use, but fast is a catastrophic property for password hashing. A modern consumer GPU can test roughly 100 billion MD5 hashes per second. An 8-character all-lowercase password has about 200 billion combinations. That's crackable in minutes.

bcrypt, scrypt, Argon2 — these are intentionally slow. They're designed to take a configurable amount of time per guess (typically a few milliseconds). A GPU that can test 100 billion MD5 hashes per second might only manage 20,000–100,000 bcrypt hashes per second. Same hardware, orders of magnitude slower. That's by design.

The problem is that you don't know what algorithm a given service uses until there's a breach. Services that still use MD5 or unsalted SHA-1 in 2026 are out there.

Dictionary Attacks

Pure brute force — trying every possible character combination — is only practical for short passwords. For anything beyond 8-10 characters, the search space is too large even for fast hardware.

The smarter approach is a dictionary attack. Attackers maintain massive wordlists assembled from:

These lists contain billions of entries. If your password appears in any of them — even as something that only you think you came up with — it will fall in the first pass.

Rules and Mutations

Wordlists don't stop at exact matches. Cracking tools apply rule-based transformations to every word automatically:

This matters because "P@ssw0rd!" looks complex but is simply "password" with standard substitutions and a trailing symbol — a transformation pattern so common it's among the first rules applied in every major ruleset. The same goes for "S3cur1ty!", "L0g1n!", and every similar construction you might have felt clever about.

The requirement to "include at least one uppercase letter, number, and symbol" doesn't make passwords harder to crack. It makes them look harder while following entirely predictable patterns.

Rainbow Tables

For the most commonly used passwords, attackers don't even need to crack anything. Rainbow tables are precomputed lookup databases: given a hash value, find the original password instantly.

If your password is "123456" or "letmein" and the service hashed it without a salt (a random value added before hashing to make each hash unique), recovery is instantaneous — it's a lookup, not a computation.

Properly salted hashes make rainbow tables useless, because the same password hashed with different salts produces different hash values. Again, whether your data is protected this way depends entirely on how the service was built.

Cracking Times in Practice

These estimates assume offline cracking against bcrypt hashes — the more secure baseline. MD5/SHA-1 cracking is dramatically faster.

Password Character Set Estimated Time (bcrypt)
8 characters Lowercase only Hours to days
8 characters Mixed case + numbers Weeks to months
12 characters Mixed case + numbers + symbols Thousands of years
16 characters Any random mix Astronomically long

Note that these assume the password is genuinely random — not a word, not a pattern. A 12-character passphrase based on real words falls much faster than a 12-character random string.

What Actually Can't Be Cracked

A password that is long, genuinely random, and not based on any word, phrase, or pattern is practically immune to all of the attacks above. It won't appear in any wordlist. No rule mutation will generate it. And brute-forcing it at any realistic speed is out of reach for current or near-future hardware.

"K9#mLpX!2rQzFw9n" at 16 characters isn't just hard to crack — it's computationally unreachable within any sensible time frame, even with MD5 hashing. Extend to 20+ characters and you've effectively solved the problem.

This is exactly why randomly generated passwords — created by cryptographic functions, not human intuition — are the right answer. They don't follow patterns. They don't appear in wordlists. They're just noise to any algorithm, no matter how sophisticated.

The pattern is the vulnerability. Every password attack exploits the predictability of human choices. Removing the human from the process — using a generator — removes the vulnerability.