Key Stretching Work Factor

A password has whatever entropy it has, and no amount of hashing adds to it. What stretching does instead is make each guess expensive: run the password through $n$ iterations of a key derivation function and an attacker's cost per guess goes up by a factor of $n$, which is $\log_2 n$ bits. It is the same total defence as adding $\log_2 n$ bits to the password, taken out of the attacker's rate rather than out of the secret. In the brute-force equation, stretching lowers $R$; it never raises $H$.

The tidy part of the bcrypt design — Provos and Mazières, USENIX 1999 — is that the cost parameter is the number of bits. A bcrypt cost of 12 means $2^{12} = 4096$ iterations and 12 added bits. scrypt and Argon2 follow the same convention for their time cost. PBKDF2 (RFC 2898) takes a raw iteration count instead, so 600,000 iterations is $\log_2 600000 = 19.19$ bits.

The sobering arithmetic is that doubling the work adds one bit. Six hundred thousand times the effort, paid by your server on every single honest login, buys nineteen bits. Which means stretching cannot rescue a weak password: twenty bits of stretching applied to a twenty-bit password is forty bits, and forty bits falls in an afternoon. What stretching genuinely does is buy time for everyone else in the database after a breach — the difference between "every password in the dump is cracked by morning" and "the strong ones survive long enough for a forced reset to matter". That is a real and worthwhile thing to buy, and it is the correct reason to do it. It is not a substitute for entropy.

Set the cost by measuring, not by copying a number from the internet. The right value is the largest one your server can absorb at peak login rate, which usually lands somewhere between 100 and 500 milliseconds per hash. Too low and you have given the attacker a discount; too high and you have built a denial-of-service vector into your own login page, because every attempt costs you as much as it costs them. Then raise it as hardware improves, which means the value should live in configuration and the stored hash should record which parameters produced it — every modern format does exactly that.

Prefer a memory-hard function. PBKDF2's iterations are pure computation, and pure computation is what a GPU does tens of thousands of at a time, so the defender's cost and the attacker's cost diverge badly on parallel hardware. scrypt and Argon2 (RFC 9106) deliberately require a large working memory as well as time, which is far harder and more expensive to parallelise; the current default recommendation is Argon2id, which resists both side-channel and time-memory-tradeoff attacks. RFC 9106 gives concrete parameter suggestions. Whichever you pick, salt every password with a unique random value — that is what stops one precomputed table from breaking every account at once, and it is orthogonal to everything on this page.