Thanks for putting the implementation caveat up front. The absolute times will look different on native bcrypt, but the four-times jump between cost 10 and 12 should still hold. The useful takeaway for me is that "just raise the cost" is a product decision, not only a security one: two seconds per login at cost 14 is something a person would feel. If someone repeats the test, timing a few concurrent hashes would be a good next step, since a login endpoint rarely runs completely alone.
Yeah, the product-decision framing is the bit I keep coming back to — two seconds is a spinner a real person stares at, and that's a UX call as much as a security one. You're right the ratios should hold on native bcrypt, the absolutes won't. And the concurrent timing is a good call — I ran these one at a time, so a busy login endpoint would look worse than my table. Haven't run that version yet.
QRiQRa Team
Thanks for putting the implementation caveat up front. The absolute times will look different on native bcrypt, but the four-times jump between cost 10 and 12 should still hold. The useful takeaway for me is that "just raise the cost" is a product decision, not only a security one: two seconds per login at cost 14 is something a person would feel. If someone repeats the test, timing a few concurrent hashes would be a good next step, since a login endpoint rarely runs completely alone.