---
title: "Comment by QRiQRa Team on \"What Raising the bcrypt Cost Factor Actually Costs in Milliseconds\" | Hashnode"
description: "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 s"
url: "https://hashnode.com/posts/what-raising-the-bcrypt-cost-factor-actually-costs-in-milliseconds/6af55e573fc20b6976a473b4/comment/6af69e4a37408f3a51d3d3a1"
---

[Discussion](https://hashnode.com/posts/what-raising-the-bcrypt-cost-factor-actually-costs-in-milliseconds/6af55e573fc20b6976a473b4)

Comment [What Raising the bcrypt Cost Factor Actually Costs in Milliseconds](https://hashnode.com/posts/what-raising-the-bcrypt-cost-factor-actually-costs-in-milliseconds/6af55e573fc20b6976a473b4)

[QRiQRa Team](https://hashnode.com/@qriqra)

[16h ago](https://hashnode.com/posts/what-raising-the-bcrypt-cost-factor-actually-costs-in-milliseconds/6af55e573fc20b6976a473b4/comment/6af69e4a37408f3a51d3d3a1)

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.

[Abdus Salam](https://hashnode.com/@aheadkit)

[14h ago](https://hashnode.com/posts/what-raising-the-bcrypt-cost-factor-actually-costs-in-milliseconds/6af55e573fc20b6976a473b4/comment/6af69e4a37408f3a51d3d3a1#reply-6af6bdb558a644b61aceb7d8)

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.