[geogriffin]

Exactly, 1000 guesses per second is probably a reasonable target to tune your KDF's difficulty to, depending on of course the application and the amount of resources you're willing to dedicate to running the KDF on every login..

[wahern]

Hackers assemble zombie clusters with hundreds of thousands of machines, if not millions of machines, each with multiple CPUs.

The number of CPUs dedicated to Bitcoin mining must be in the hundreds of millions.

1000 guesses per second * 100 million CPUs... good luck with your linear work factor KDF protecting your short password.

[geogriffin]

I think if my password is worth 17.5 trillion CPU seconds then I'm a very lucky person...

[wahern]

That's great, but that's not how you approach security engineering.

It's like security through obscurity. Operationally it may have value, but you don't premise your security on such an approach.

Relying on a cost factor-based KDF is like relying on the grizzled machine engineer in the basement who keeps things humming along with wire and duct tape. Great if it works for you, but it's ridiculous to sit down at a table among engineers discussing design elements and say, "Hey, this is a crappy and fundamentally broken design, but I got guy who might be able to make it work for a little while."

Imagine if we "fixed" TLS AES-CBC or similar probabilistic active MITM leaks by simply running the AES-CBC cipher a few thousand additional times over each block, reducing the rate at which an attacker could iteratively reveal the plain text by rate-limiting throughput at the ends. It'd be a ludicrous proposal. Yet that's exactly what cost factor-based KDFs do.

[geogriffin]

I see your point. Especially since cost-based KDFs rely on the predicted characteristics of future hardware.