Bcrypt Hash Generator & Verifier

About this tool

Why bcrypt is slow on purpose

Password databases get stolen, and whoever has one can guess passwords offline, as fast as their hardware allows. General-purpose hashes such as SHA-256 are built to be fast, so a single graphics card tries billions of candidates per second. bcrypt, published by Niels Provos and David Mazières in 1999, is built on the expensive key setup of the Blowfish cipher and repeats it a configurable number of times, which makes every guess costly.

Each hash also carries its own random 16-byte salt. Two users with the same password get different hashes, and a table computed in advance for one salt is useless for the next. A bcrypt hash cannot be decrypted. The practical attack is guessing, so a weak password still falls quickly whatever the cost.

What the cost means and how to pick one

The cost is the base-2 logarithm of the number of key-setup rounds: cost 10 is 1,024 rounds, cost 12 is 4,096. Adding one doubles the time for a login and for every guess an attacker makes. The cost is written into the hash, so you can raise it later: old hashes keep verifying, and you can rehash a password at the new cost the next time its owner logs in.

Choose the highest cost your server can afford for a login, and not less than 10, which is the minimum the OWASP Password Storage Cheat Sheet gives for bcrypt. The time shown here is measured in WebAssembly in your browser, which is usually slower than native code on a server, so measure on the machine that will do the hashing. This tool stops at cost 14 for that reason.

The 72-byte limit

bcrypt uses at most 72 bytes of the password. The limit is in bytes, not characters: in UTF-8 an accented letter such as é takes two bytes, most CJK characters three and most emoji four or more. Many libraries cut longer input without saying so, which means two long passwords that share their first 72 bytes verify against the same hash. The Go implementation used here refuses to hash longer input, and this tool tells you when that happens.

If your users may choose longer passwords, the plain answer is to reject them at sign-up with a clear message. A common workaround hashes the password first with SHA-256 and passes the Base64 or hex text of that digest to bcrypt. It must not pass the raw digest bytes, because some implementations stop reading at a zero byte, and the OWASP cheat sheet advises against this kind of pre-hashing because it opens the way to an attack called password shucking. For a new system, OWASP recommends Argon2id ahead of bcrypt, and Argon2id has no 72-byte limit.

Reading a hash, and how this tool runs

A bcrypt hash is 60 characters: a version prefix such as $2b$, a two-digit cost and $, 22 characters of salt and 31 characters of digest, both in bcrypt's own Base64 alphabet (./A-Za-z0-9). Everything needed to check a password is in that one string, so there is no separate salt column to store.

Hashing and checking are done by Go's golang.org/x/crypto/bcrypt package compiled to WebAssembly and run in a background thread of your browser. Passwords and hashes are not sent anywhere and are not stored. The page is meant for test data, fixtures and checking a hash you already have: passwords of real users should be hashed by your application, on your server.