The bcrypt cost factor is a single number that controls how secure your password hashes are. It also controls how long your users wait to log in. Get it right and you have strong protection with a smooth user experience. Get it wrong and you either leave passwords vulnerable or make every login painfully slow.
Let's break down exactly what the cost factor does, what numbers make sense in 2026, and how to adjust it over time.
What the Cost Factor Actually Does
The bcrypt cost factor is a number (typically between 4 and 31) that determines how many times the internal key scheduling algorithm runs. The relationship is exponential: the algorithm runs 2^n iterations, where n is the cost factor.
Here is what that means in practice:
- **Cost 4**: 2^4 = 16 iterations. Takes about 1 millisecond. Fast enough for interactive use, but trivially fast for attackers too. - **Cost 10**: 2^10 = 1,024 iterations. Takes about 100 milliseconds. A good default for most applications. - **Cost 12**: 2^12 = 4,096 iterations. Takes about 400 milliseconds. Strong protection, still acceptable for logins. - **Cost 14**: 2^14 = 16,384 iterations. Takes about 1.6 seconds. Too slow for interactive login on most servers. - **Cost 16**: 2^16 = 65,536 iterations. Takes about 6.5 seconds. Useful for offline hashing of high-value secrets, not for web logins.
The key thing to understand is that each increment doubles the time. Going from 10 to 11 does not add 10% more work. It adds 100% more work. This exponential scaling is what makes bcrypt future-proof. When hardware gets twice as fast, you bump the cost factor by one and you are back to the same level of security.
Benchmarking on Your Own Hardware
The numbers above are rough averages. The actual time depends on your server's CPU. A fast desktop processor will hash much quicker than a shared cloud instance with limited CPU allocation.
The best practice is to benchmark on your production hardware. Here is a simple approach: generate a bcrypt hash at each cost factor from 8 to 15 and time how long it takes. Pick the highest cost factor where hashing completes in under 250 milliseconds for interactive logins, or under 500 milliseconds if you can tolerate slightly longer waits.
You can experiment with this directly using our bcrypt generator. Try hashing the same password at cost 10, 12, and 14 and feel the difference in response time.
Recommended Cost Factors for 2026
Hardware has come a long way since bcrypt was introduced in 1999. GPUs that can compute billions of SHA-256 hashes per second are cheap and accessible. Here is what we recommend in 2026:
**Cost 10** — Good baseline. About 100 milliseconds per hash. Suitable for most web applications with average security needs. An attacker would need roughly 3 hashes per second per GPU, making large-scale cracking expensive.
**Cost 12** — Recommended for most applications. About 400 milliseconds per hash. This is the sweet spot for 2026. It is still fast enough for interactive logins (users will not notice 400ms) but slow enough to make brute-force attacks impractical for all but the most determined attackers.
**Cost 14** — For high-value targets. About 1.6 seconds per hash. Use this for applications where the stakes are particularly high (financial services, healthcare, admin accounts). The 1.6 second delay may be noticeable to users, so consider using it only for sensitive operations or running it asynchronously.
**Cost 4-6** — Do not use these in production. They were reasonable in the early 2000s but are trivially fast for modern hardware. If you have an old database with these cost factors, plan a migration.
The User Experience Tradeoff
Here is the tension at the heart of the cost factor: every millisecond you add to hashing makes your application more secure but slower for users.
For a typical login flow, the user submits their password, your server hashes it, compares it to the stored hash, and either grants or denies access. The hashing step is the bottleneck. At cost 10, this takes 100ms. At cost 14, it takes 1.6 seconds.
Most users will tolerate up to about 500ms of latency without noticing. Beyond that, logins start to feel sluggish. At 1.6 seconds, users will definitely notice the delay, and some may think the site is broken.
There is also a denial-of-service consideration. If your login endpoint takes 1.6 seconds per request, an attacker sending 100 login requests per second can tie up 160 CPU-seconds of work per second. On a single-core server, this would completely overwhelm the system. At cost 10 (100ms per request), the same attack only ties up 10 CPU-seconds per second, which is much more manageable.
The lesson: do not set the cost factor as high as possible. Set it as high as your user experience and server capacity allow.
When and How to Increase the Cost Factor
One of bcrypt's best features is that you can increase the cost factor over time without resetting passwords. The strategy is simple:
1. When a user logs in, bcrypt verifies their password using the cost factor stored in their existing hash. 2. If the stored cost factor is lower than your target, you re-hash the password (which you now have in plaintext because the user just logged in) with the new, higher cost factor. 3. You store the new hash, replacing the old one.
This means you gradually upgrade your entire database over time as users log in. Users who have not logged in recently keep their old cost factor, but that is fine. The important thing is that active users get upgraded automatically.
You can read more about this pattern in our bcrypt explained post, which covers the full hash format and how the cost factor fits into it.
A Practical Decision Framework
If you want a simple rule for 2026: start with cost 12. Benchmark it on your production hardware. If it takes less than 250 milliseconds, consider bumping to 13. If it takes more than 500 milliseconds, drop to 11. Re-evaluate every two to three years as hardware improves.
The cost factor is not a set-and-forget setting. It is a dial you should revisit periodically. Hardware gets faster every year, and what was secure at cost 10 in 2020 might warrant cost 12 in 2026. The beauty of bcrypt is that adjusting this dial is all you need to do.
Try different cost factors yourself with our bcrypt generator and see how the timing changes.
