bcrypt Work Factors Double With Each Increment — Here's How to Choose the Right One and Upgrade Existing Hashes

bcrypt's work factor (cost factor) doubles the hashing time for every increment — and this exponential relationship is the entire point, designed so that future hardware improvements can be compensated for with a single number change

The previous articles on this site covered bcrypt basics, bcrypt history and Argon2 comparison, credential breaches and HIBP, and bcrypt's 72-byte limit. This article addresses work factor selection and management over time — specifically how to choose the right work factor now, how to upgrade work factors for existing password hashes without forcing a re-login, and what "doubling" means in practice when hardware gets faster.

The doubling relationship: what increasing work factor by 1 actually means

bcrypt's work factor (also called cost factor, passed as the second parameter in most implementations) is the logarithm base 2 of the number of iterations. Work factor 10 = 2^10 = 1,024 iterations; work factor 11 = 2^11 = 2,048 iterations; work factor 12 = 2^12 = 4,096 iterations.

Each increment of 1 doubles the computation time:

• Work factor 10: ~100ms on a modern CPU
• Work factor 11: ~200ms
• Work factor 12: ~400ms
• Work factor 13: ~800ms
• Work factor 14: ~1,600ms (1.6 seconds)

This doubling is the design feature, not a coincidence. As hardware gets faster — a general-purpose CPU that takes 100ms at work factor 10 today might take 50ms in 5 years at the same work factor — incrementing the work factor by 1 restores the original time cost. Hardware improvements are roughly linear; the work factor compensates exponentially.

Choosing the initial work factor: the "100ms rule"

The most common guidance for web applications: choose the work factor that makes bcrypt take approximately 100-300ms on your production hardware.

Why 100-300ms?

• Security: slow enough that an attacker brute-forcing a leaked hash database can only attempt a few thousand hashes per second per CPU core, rather than millions (as with fast hashes like MD5 or SHA-256)
• User experience: fast enough that a user logging in doesn't notice the delay — login is a once-per-session event, and 100ms is imperceptible
• Server load: at typical login rates, the CPU time per authentication is manageable — even at 1,000 logins/second, 100ms/login requires 100 CPU-cores worth of computation, which is worth planning for but not prohibitive

How to calibrate: run bcrypt on your actual production hardware (not your development laptop) and measure the time at different work factors. Find the factor where hashing takes approximately 200ms, then verify that this remains acceptable at your expected peak login rate.

Upgrading work factors for existing hashes: the incremental re-hash strategy

A deployed application has passwords hashed at the original work factor. When hardware improves or security requirements increase, you want to upgrade to a higher work factor — but you can't re-hash stored passwords without knowing the original passwords.

The standard strategy: opportunistic re-hashing on successful login.

When a user successfully logs in (at which point you have their plaintext password to verify against the stored hash):

1. Verify the password against the existing hash (confirming it's correct)
2. If the stored hash uses an old work factor, re-hash the plaintext password with the new (higher) work factor
3. Store the new hash, replacing the old one

The result: active users' passwords are gradually upgraded to the new work factor as they log in. Users who haven't logged in recently still have the older hash — acceptable, because they're less likely to have been targeted (haven't recently interacted with the service), and their hash will be upgraded on their next login.

No forced logout, no password reset email, no user-facing disruption — the upgrade happens silently during normal authentication.

Detecting the work factor from a stored hash

bcrypt hashes have a self-describing format — the hash string itself encodes the work factor used:

$2b$12$LF1jGFnhTT4k9hYO9VQMhOxnFqbHLJmDe6sNIgMJqOgpGwXKiVqVi

Breaking this down:

• $2b$ — bcrypt version identifier
• 12 — work factor (12 in this case)
• Next 22 characters — the 128-bit salt (Base64 encoded)
• Remaining characters — the actual hash

This self-describing format enables the opportunistic re-hash strategy — when verifying a login, you read the work factor from the stored hash, and if it's below the current target work factor, you know to re-hash after successful verification.

Bcrypt for non-password data: when it's appropriate and when it's not

bcrypt is designed for password hashing — specifically for the use case where you need to:

1. Verify that a presented value matches a stored hash
2. Make brute-force attacks against the stored hash computationally expensive

Appropriate uses: passwords, PINs, security questions, other user-presented secrets that need to be verified but not retrieved.

Inappropriate uses:

• API keys that need to be retrieved/displayed: bcrypt is one-way; you can't recover the original value. API keys shown to users after creation need reversible storage (encryption, not hashing), or must be stored and displayed only once at creation time and not again
• Large data: bcrypt's 72-byte input limit (covered in the previous article) makes it unsuitable for hashing arbitrary-length data
• High-volume data verification: bcrypt is intentionally slow; using it to hash millions of records per minute is inappropriate — use SHA-256 or similar fast hashes for data integrity verification where the adversarial brute-force protection isn't needed

How to use the Bcrypt Generator on sadiqbd.com

1. For testing work factors: hash the same password at different work factors (10, 12, 14) and observe the relative times — use this to calibrate what work factor is appropriate for your hardware
2. For verifying bcrypt implementations: the generator can confirm that a given password matches a given hash, useful when debugging bcrypt library behavior across different language implementations
3. For understanding the hash format: inspect a generated hash to read the work factor, salt, and understand the self-describing format that enables automatic work-factor detection in application code

Frequently Asked Questions

If I upgrade the work factor, do I need to update my authentication code? No, if you're using a standard bcrypt library correctly. Standard bcrypt libraries extract the work factor from the hash string automatically during verification — your verification call doesn't need to know which work factor was used to create the hash; the library reads it from the hash itself. The only change needed when upgrading is: in the hashing code path (where new hashes are created or existing ones re-hashed), use the new, higher work factor. The verification code path works unchanged because it reads the factor from the hash.

Is the Bcrypt Generator free? Yes — completely free, no sign-up required.

Try the Bcrypt Generator free at sadiqbd.com — generate and verify bcrypt password hashes with configurable work factors.