bcrypt cost is login latency
Sumit Jha · Updated 2026-11-06
bcrypt hashes a password with a salt and a cost. You cannot reverse the hash. Cost is a work factor: each increment is slower. Pick a cost your login handler can afford under load, not the largest number the slider allows. A fast hash such as a single SHA-256 is the wrong tool for passwords.
What the cost factor changes
bcrypt’s cost is logarithmic. Cost 12 does far more work than cost 10. The point is to make guessing expensive. The side effect is that your own checkPassword call pays the same bill. A cost that takes 800ms on a laptop can time out a small server that handles many logins at once.
Measure on hardware close to production. The DevTooKit control tops out around cost 14 so a browser tab stays usable. Your server policy might want a different number. The string you store starts with $2a$ or $2b$, then the cost, then the salt and hash. You do not store the cost separately.
Verification is a compare, not a decrypt
To check a password you hash the candidate with the salt and cost embedded in the stored string and compare. A match means that password produced that string. It does not recover other passwords and it does not tell you the original if you lost it.
MD5 and SHA-256 of a password are not substitutes. They are fast, often unsalted in amateur code, and easy to precompute. Use them for checksums of files and strings. Use bcrypt, scrypt, or argon2 for passwords.
Do not hash production passwords in a random browser
A local bcrypt demo is useful to feel the latency. Pasting a real user’s password into any page, including a local-first one, still puts that password in the tab, in extensions, and possibly in a crash dump. Generate test passwords locally, and run production hashing inside the service that stores the result.
How to pick a cost without guessing
Hash the same test password at cost 10, 12, and 14 and write down the time. The gap is the product decision. A cost that feels fine once in a form is paid again on every login and on every password-reset confirmation. If the hash takes most of your request budget, lower the cost or move the hash off the request thread. Raising the cost later means rehashing on next login, which is normal, but you have to write that path.
The stored string is the whole record. It includes the algorithm prefix, the cost, and the salt. You do not need a separate salt column, and you must not strip the prefix before you verify. Two hashes of the same password differ because the salt differs. Comparing the strings with === is wrong. Use the library’s compare function, which is constant-time in decent implementations.
A password generator belongs next to this tool only for fixtures. It does not check breach lists, and a hash you computed in the browser is not a migration of your user table. SHA-256 of a password remains a fast hash even if you add a salt by hand. The work factor is the part that matters, and SHA-256 does not have one.
Write down the time you measured and the cost you chose in the same note as the library version. bcrypt prefixes $2a$ and $2b$ are not interchangeable across every implementation, and a hash produced in the browser is only a latency sample. Your server should hash with the library you deploy. If login p99 moves when you bump the cost, that is the feature working. Cap the cost so a single request cannot ask for cost 31 and stall a worker. The slider on this site stops well below that, on purpose, because a tab is a bad place to discover an accidental denial of service.
FAQ
Can I reverse a bcrypt hash?
No. Verification checks a candidate. It does not print the original password.
Is a higher cost always better?
Only if login latency stays acceptable. Cost is paid on every check, including yours.
Related tools
- Password GeneratorGenerate strong, configurable passwords with entropy meter.
- Hash CalculatorGenerate MD5, SHA-1, SHA-256, SHA-512 and Blake3 hashes from text.
Limitation: this note describes the DevTooKit tool and the general rule behind it. Production libraries, clocks, and schedulers can differ. Check those docs before you ship.