What cost factor should I use?

OWASP recommends cost factor 10 minimum; 12 is the current recommended default. Calibrate to your production server: the hash should take 150-500ms. Higher is better, within that constraint.

Why does bcrypt have a 72-byte password limit?

The limit comes from bcrypt's internal Blowfish key setup. Input beyond 72 bytes is silently ignored. For longer passwords, a common mitigation is to pre-hash the password with SHA-256, then bcrypt the hex digest.

Is bcrypt still recommended over Argon2?

For new systems, Argon2id is preferred — it is memory-hard, making GPU attacks more expensive. bcrypt is still secure and widely supported, so migrating existing systems is not urgent but worth doing for new projects.

Bcrypt Simulator | DevTools Surf

DevTools Surf

Example: Bcrypt Simulator

A worked example, rendered from real sample data. Sign in to run the tool on your own input.

Input

correct horse battery staple

Output

═══ What this tool does ═══
ℹ It runs REAL bcrypt (the bcryptjs library) on our server, times it, and uses that measurement to plan a cost factor. Nothing is faked.
ℹ Costs 13 and above are extrapolated by doubling, because each step costs twice as much and measuring cost 15 would hold the request open for half a minute.
ℹ bcryptjs is pure JavaScript. A native bcrypt on the same machine is typically two to four times faster, so read the SHAPE of the curve, then calibrate on your own hardware.
ℹ To hash or verify a specific password, use the Bcrypt Hash Tester instead. This tool is for choosing the cost.

═══ Measurement ═══
Password length: 28 characters
Cost 8: 45 ms measured (256 key-setup rounds)
Cost 9: 71 ms measured (512 key-setup rounds)
Cost 10: 336 ms measured (1,024 key-setup rounds)
Cost 11: 861 ms measured (2,048 key-setup rounds)
Cost 12: 1.7 s measured (4,096 key-setup rounds)
Anchor: cost 12 at 1.7 s

═══ Cost table (target 250 ms per login) ═══
  cost   hash time    logins/s      GPU guesses/s   crack a 40-bit secret
  -----------------------------------------------------------------------
  8      45 ms        88            23000           277 d   (measured)
  9      71 ms        56            11500           1.5 y   (measured)
  10     336 ms       12            5750            3.0 y   (measured)
  11     861 ms       4.6           2875            6.1 y   (measured)
  12     1.7 s        2.4           1438            12.1 y   (measured)
  13     3.4 s        1.2           719             24.2 y
  14     6.8 s        0.6           359             48.5 y
  1
…

About Bcrypt Simulator

Bcrypt Simulator preview - Security / Crypto tool

Time real bcrypt on the server and pick the highest cost factor your login budget allows. Part of the DevTools Surf developer suite. Browse more tools in the Security / Crypto collection.

Use Cases

Choose the right bcrypt cost factor for a given server's CPU budget
Verify that password hashing takes enough time to deter brute-force attacks
Demonstrate the relationship between cost factor and computation time
Compare bcrypt performance against Argon2 or scrypt for architecture decisions

Tips

Cost factor 12 is the current OWASP minimum recommendation — benchmark your server to find the highest value that stays under 500ms
The simulator shows actual time taken at each cost factor; use it to calibrate before deploying to production hardware
bcrypt truncates input at 72 bytes — passwords longer than that are silently trimmed. Pre-hash with SHA-256 if you need to support longer passwords

Fun Facts

bcrypt was designed by Niels Provos and David Mazieres in 1999 and presented at USENIX. It was one of the first password hashing schemes to use an adaptive cost factor — making it slower as hardware gets faster.
The default cost factor in most frameworks is 10 (1,024 rounds). Cost factor 12 requires about 4x the compute of cost factor 10. Cost factor 14 requires 16x. Each increment of 1 doubles the work.
Despite being 25 years old, bcrypt remains widely recommended because its deliberate slowness has kept it resilient to GPU attacks. SHA-256, by contrast, can be computed billions of times per second on commodity hardware — making it unsuitable for passwords.

FAQ

What cost factor should I use?: OWASP recommends cost factor 10 minimum; 12 is the current recommended default. Calibrate to your production server: the hash should take 150-500ms. Higher is better, within that constraint.
Why does bcrypt have a 72-byte password limit?: The limit comes from bcrypt's internal Blowfish key setup. Input beyond 72 bytes is silently ignored. For longer passwords, a common mitigation is to pre-hash the password with SHA-256, then bcrypt the hex digest.
Is bcrypt still recommended over Argon2?: For new systems, Argon2id is preferred — it is memory-hard, making GPU attacks more expensive. bcrypt is still secure and widely supported, so migrating existing systems is not urgent but worth doing for new projects.

Related Security / Crypto Tools

Hash Generator v2 HMAC Generator v2 JWT Encoder Bcrypt Hash Tester HMAC Generator Password Strength Analyzer TOTP / 2FA Generator SAML Response Decoder