Password Hashing and Offline Cracking: Why Work Factor Beats Complexity

Offline password cracking is what happens after a breach. The attacker has the hashes and no longer has to talk to your service, so rate limiting, lockout and monitoring are all irrelevant. What remains is arithmetic: how many guesses per second the attacker can make, and how many guesses your passwords require.

Why hashing, and why that is not enough

Storing passwords hashed means a breach does not immediately reveal them. Hashes are one-way, so the attacker must guess a candidate, hash it, and compare.

The problem is speed. General-purpose hash functions were designed to be fast, which is exactly wrong here — a modern GPU computes billions of fast-hash guesses per second, and dedicated hardware does far more. Against that rate, any password a human chose and can remember falls quickly.

So a password hash function needs to be deliberately slow, and slow in a way that does not help the attacker more than the defender.

Salting

A salt is a unique random value stored alongside each hash and included in the computation. It does not slow anything down, and it changes the economics completely.

Without salts, identical passwords produce identical hashes, so an attacker sees which users share a password and cracks each distinct value once for the whole database. With unique salts, every hash must be attacked separately.

Salts also defeat rainbow tables — precomputed lookup structures trading storage for computation. A precomputed table is built for one hash function with no salt; add a unique salt per password and the precomputation cannot be reused. This is the specific reason salting is always the answer to a rainbow table question.

A pepper is a secret value added to every hash and stored separately from the database, often in a hardware security module. If only the database leaks, the hashes cannot be attacked at all without it.

Work factor and memory hardness

Modern password hashing functions take a cost parameter, so the defender chooses how slow the function is. Raise the work factor and both defender and attacker slow down by the same multiple — but the defender does this once per login and the attacker does it billions of times, so the asymmetry favours the defender enormously.

bcrypt has a cost parameter and has held up well for decades. PBKDF2 is iteration-based, widely certified and, being computationally cheap per iteration, benefits attackers with GPUs more than the alternatives do. scrypt and Argon2 add memory hardness, requiring a configurable amount of memory per computation, which is what blunts the specialized-hardware advantage — GPUs and ASICs have enormous parallel compute and comparatively limited memory bandwidth.

Argon2 is the current recommendation for new systems. Tune the parameters to the slowest value your login latency budget tolerates, and revisit them as hardware improves — a work factor chosen eight years ago is now eight years too cheap.

How attacks actually run

Attackers do not brute force randomly. They start with lists of previously breached passwords, because people reuse, then apply rule-based mangling — capitalizing the first letter, appending a year, substituting characters — which is precisely the transformation composition rules push people toward. That is why complexity requirements add so little: the search space they create is the space attackers search first.

Targeted attacks add organization-specific wordlists — the company name, product names, local sports teams, the current season.

Length is what defeats this, because each additional character multiplies the space regardless of what the characters are. A long passphrase of ordinary words beats a short mangled password decisively, which is the reasoning behind the guidance under password policy — and why multi-factor authentication matters more than any hashing decision, since it removes the password as a single point of failure.

Where else offline cracking applies

Not just password databases. Captured authentication material is crackable offline too — Kerberos service tickets from Kerberoasting, NTLMv2 challenge-response pairs, WPA handshakes. In each case the defence is the same: the secret must be long and random, because nothing else about the exchange can be made slow.

Password managers and encrypted archives are cracked the same way, which is why their key derivation functions also use work factors.

Exam angles

Know that offline cracking is unaffected by lockout, rate limiting and monitoring, which is why password length and hash strength are what matter. Know salting as the defence against rainbow tables and against identical hashes revealing shared passwords, and pepper as a separately stored secret. Identify bcrypt, scrypt, PBKDF2 and Argon2 as password hashing functions with tunable work factors, memory hardness as the property that resists specialized hardware, and general-purpose fast hashes as unsuitable for password storage.