Bcrypt password hash generator

Reading that strange string it gives you

A bcrypt hash looks like line noise, but it has a fixed anatomy worth knowing. It opens with a version marker such as $2a$ or $2b$, followed by the cost factor you chose, then twenty-two characters of the random salt, and finally the thirty-one characters of the actual hash. Everything a verifier needs travels inside that one string — which is why the whole thing fits in a single database column, and why generating a hash for the same password twice gives two different strings that are nonetheless both valid. The salt differs each time, so the output differs each time; when your backend later checks a login, it reads the salt back out of the stored string, hashes the attempt with it, and compares the result.

Where you would actually use this page

Most of the time bcrypt hashing happens inside your application, not in a browser — but there are moments when a hand-made hash is exactly what you need. Seeding a test database with accounts whose passwords you know. Rescuing a locked-out admin account by writing a fresh hash straight into the users table. Checking what shape of string a library will produce before you size the column for it. In all of these you paste a password, copy the hash, and place it where your login code expects one. One thing never to do: compare hashes as strings in your own code. Because of the salt, the same password produces different hashes — verification must go through your library's compare function, which knows how to read the salt back out.

Picking a cost you can live with

Each step in the cost factor doubles the work, for you and for an attacker alike. Eight is quick and best left to legacy compatibility; ten, the default here, is the common production choice; twelve buys comfort if logins are rare; fourteen takes seconds even to generate. A fair warning about timing: this page runs a pure JavaScript implementation, which is slower than the native code on your server, so treat the delay you feel here as an upper bound rather than a benchmark — measure on the machine that will actually handle the logins. And since a hash is only as good as what goes into it, the password generator makes a strong input, while anything that is not a password — files, documents, plain text — belongs with the SHA hash generator instead.

Why bcrypt instead of a plain hash

A plain SHA hash of a password can be brute-forced fast on modern hardware. Bcrypt is deliberately slow — the cost factor controls exactly how slow — and salts automatically, so the same password never produces the same stored hash twice. That's why it's still a standard choice for storing passwords server-side.