---
title: "Discussion on \"What Raising the bcrypt Cost Factor Actually Costs in Milliseconds\" | Hashnode"
description: "Discussion on \"What Raising the bcrypt Cost Factor Actually Costs in Milliseconds\". Somewhere in your codebase there is a line that looks like this:\nconst hash = await bcrypt.hash(password, 10);\n\nThat 10 is the cost factor, and most tutorials tell you to set it to 10, or 12, and move"
url: "https://hashnode.com/posts/what-raising-the-bcrypt-cost-factor-actually-costs-in-milliseconds/6af55e573fc20b6976a473b4"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [What Raising the bcrypt Cost Factor Actually Costs in Milliseconds](https://aheadkit.hashnode.dev/what-raising-the-bcrypt-cost-factor-actually-costs-in-milliseconds?utm_source=hashnode&utm_medium=feed)

Somewhere in your codebase there is a line that looks like this: const hash = await bcrypt.hash(password, 10); That 10 is the cost factor, and most tutorials tell you to set it to 10, or 12, and move

1d ago · 5 min read · aheadkit.hashnode.dev  
Read the article

-   [#security](https://hashnode.com/tag/security)
-   [#node](https://hashnode.com/tag/node)
-   [#javascript](https://hashnode.com/tag/javascript)
-   [#programming](https://hashnode.com/tag/programming)

## Written by

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

@aheadkit

  
[View profile](https://hashnode.com/@aheadkit)

## Responses 2

Markdown supported · ⌘↵ to post

[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)

[13h 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.