🧂bcrypt Cost Factor Guide

Scale measured hash time across cost factors

cost
ms
ms
/s
costProjected timeThroughputVs target

Times in the table come from your own measurement scaled by the bcrypt property that each step of 1 in cost doubles the work. No hardware benchmark figures are built in, so measure on your own server first. Source: OWASP Password Storage Cheat Sheet (checked October 2026).

You Might Also Need

How to use the bcrypt cost factor guide

Enter the cost you are running today, the time one hash took when you measured it, and the latency you want to stay under. The page projects the time at every other cost and reports the highest cost that still fits your target. bcrypt doubles its iteration count for each step of 1 in cost, so a single measurement is enough to scale the rest. Add your peak logins per second and you also get the number of CPU cores that load would need.

How the projection works

Projected time is your measurement multiplied by 2^(target cost minus measured cost); no hardware benchmark table is used. The guidance comes from the OWASP Password Storage Cheat Sheet, checked in October 2026, which recommends Argon2id for new systems, treats bcrypt as legacy with a work factor of 10 or more, suggests keeping one hash under a second, and says there is no golden rule for the ideal value.

Limits worth knowing

Nothing is hashed here, so a sloppy measurement produces a sloppy projection. Measure on the same CPU and under the same load as production. Pushing the cost too high turns a login burst into a self-inflicted denial of service, so judge it against peak load rather than an idle box. The password field only checks the 72-byte limit, so never paste a password you actually use. Treat these numbers as input to a security decision, not the decision itself, and review the change with the engineer who owns the system.

Frequently Asked Questions

What work factor should I pick?

OWASP states plainly that there is no golden rule for the ideal work factor. It depends on your server and your login load, so the practical route is to measure on your own hardware and take the highest value that still fits your latency target.

Is a higher cost always safer?

Every step up doubles the CPU cost of one hash, so a burst of login attempts exhausts your cores first. An attacker can stall the service just by sending login requests, which is why under one second per hash is the usual guidance.

Should I use bcrypt for a new service?

OWASP recommends Argon2id for new systems and treats bcrypt as legacy with a work factor of 10 or more. Use this tool for tuning the cost where bcrypt is already in place.