How Password Cracking Actually Works, and What It Means for Your Policy

Password policy arguments usually happen without reference to how passwords are actually broken. Once you follow the real process, most of the familiar rules turn out to defend against the wrong thing.

Online versus offline

Guessing at a live login page is slow and noisy. Rate limiting, lockouts and monitoring all apply, and an attacker gets a handful of attempts before being blocked.

Offline cracking is the real threat. Having stolen a database of password hashes, the attacker works on their own hardware with no rate limits, no lockouts and nobody watching. Modern consumer graphics hardware tests enormous numbers of candidates per second against a fast hashing algorithm.

Everything that follows is about making that offline work expensive.

Your hashing algorithm matters more than your complexity rules

A general-purpose hash such as SHA-256 is designed to be fast, which is exactly wrong for passwords. Password hashing algorithms are deliberately slow and tunable: bcrypt, scrypt and Argon2 exist to make each guess cost real time and memory.

The practical difference is enormous. The same password that falls in minutes under a fast general-purpose hash can take an impractical amount of time under a correctly configured password hash. Argon2id is the current default recommendation; bcrypt remains acceptable with an appropriate cost factor.

Salting — a unique random value per password — is non-negotiable, and it is what stops one precomputed table breaking every account at once. It does not slow down cracking a single targeted password, which is why salt alone is not enough.

How attackers actually guess

Not by brute force through every combination. In order of effectiveness:

• Wordlists from previous breaches. Billions of real passwords people have genuinely used. If a password has appeared in any breach, it is tried immediately.
• Rule-based mutation. Take each word and apply the transformations humans apply: capitalise the first letter, append a year, swap a for @, add an exclamation mark. This is why P@ssw0rd1! satisfies every complexity rule and falls instantly.
• Targeted wordlists. Company name, product names, local sports teams, the city. Generated in minutes from a website.
• Masks. Exploiting predictable structure — capital letter, six lowercase, two digits, one symbol — which is precisely the structure complexity rules produce.

Brute force only becomes relevant for short passwords or as a last resort.

What this means for policy

Composition rules push users toward predictable patterns that attackers model explicitly. Current guidance from standards bodies has moved away from them for good reason.

What actually helps:

• Length over composition. A long passphrase of ordinary words beats a short complex string, and people can remember it.
• Screen against breached password lists at the point the password is set. This blocks the entire first category of attack and is the highest-value single change available.
• Stop forced periodic rotation unless there is evidence of compromise. Rotation produces incrementing suffixes, which are trivially modelled.
• Allow password managers. Blocking paste makes unique passwords impractical and achieves nothing defensively.
• Deploy multi-factor authentication. It is the control that holds when the password fails, and phishing-resistant factors hold when the others do not.

Credential stuffing is the more common attack

Most account takeovers involve no cracking at all. An attacker takes username and password pairs from an unrelated breach and tries them against your login page, because reuse is widespread.

Defending against this requires different controls: breached-credential screening, multi-factor authentication, detection of distributed login attempts across many accounts, and rate limiting applied per account rather than per address.

Frequently asked questions