Passwords & Hashing
Bcrypt Cost Factor Explained in Plain English
How bcrypt cost works, why slower can be safer, and how to think about tuning without turning your login flow into a support issue.
In brief
What it is: The bcrypt cost factor controls how expensive each password hash operation is for both attackers and defenders.
Why it matters: Choosing a realistic cost lets you slow down offline guessing without making logins or resets feel unreliable.
Worth knowing: Time candidate cost values on the hardware that will actually verify passwords, then record the chosen latency target.
Bcrypt’s cost factor controls how expensive each password-hash operation is. That matters because password hashing is supposed to be slow enough to raise the price of guessing attacks, while still being fast enough for a normal user login or signup flow.
Many teams either ignore the setting completely or crank it up without testing. The better approach is to understand what the cost is doing and choose a setting that fits your real environment.
What the cost factor changes
- A higher cost means more work for both your system and an attacker trying guesses.
- A lower cost means faster responses, but less resistance to large-scale guessing.
- There is no universal perfect number; the right choice depends on your environment, expected load, and review cycle.
- The important operational habit is periodic re-evaluation instead of picking a value once and forgetting it.
Mistakes that waste time
- Leaving the original cost unchanged as hardware and traffic patterns evolve.
- Copying a cost value from a random article without testing your own environment.
- Assuming “higher is always better” even if it harms user-facing reliability.
- Using bcrypt cost discussions as a substitute for broader password-policy and rate-limit design.
What still needs clarification
Does a higher bcrypt cost always mean stronger security?
It means more work per guess, but it also means more work for your own systems. The best value is the one you can support operationally.
Can I change the cost later?
Yes. Many systems rehash passwords with newer settings as users log in or during planned migration work.
Why is cost visible in the hash string?
So the verifier knows how to reproduce the same work factor when checking a submitted password.
Reproduce it with exact bytes
- Freeze the exact input bytes, including encoding and newline handling.
- Generate or verify the digest with a small known sample.
- Record the algorithm, comparison rule, and storage format where future maintainers can find it.
1. exact input bytes
2. hash or HMAC operation
3. constant-format comparison
4. document algorithm and encoding
