Cybersecurity & Privacy

Understanding the Bcrypt Cost Factor: Balancing Security and Performance

What the Cost Factor Actually Controls

Bcrypt's cost factor is a number, typically between 4 and 31, that determines how many rounds of internal key setup the algorithm performs — specifically, 2 raised to the power of the cost factor. A cost of 10 means 1,024 rounds; a cost of 12 means 4,096 rounds. Because the relationship is exponential, each single increment roughly doubles the computation time required.

Why This Matters in Practice

Choosing a Reasonable Value

A commonly cited target is roughly 250 milliseconds of computation time on your actual production hardware — fast enough that legitimate users don't notice a delay, slow enough to meaningfully deter large-scale offline guessing. Many modern systems default to a cost factor around 12 as a reasonable starting point, though the right value depends on your specific hardware and how much login latency your application can tolerate.

Revisiting the Cost Factor Over Time

As hardware gets faster, a cost factor that was appropriately slow several years ago becomes proportionally faster (and therefore less protective) over time. It's reasonable practice to periodically re-evaluate your cost factor and increase it when hardware improvements have made the current value less effective than originally intended — existing hashes remain valid at their original cost factor, since that value is stored within the hash string itself; only newly generated hashes need to use the updated value.

Experimenting Safely

If you want to get a feel for how cost factor affects computation time, generating a few hashes at different cost values and comparing how long each takes is a straightforward way to build intuition — doing this with a client-side tool means you can experiment freely without sending anything to a server.

Ready to experiment with bcrypt cost factors?

Try the Bcrypt Tool