Bcrypt generator and checker

bcrypt was published by Niels Provos and David Mazières in 1999. It is built on the Blowfish cipher, with a deliberately expensive key setup that runs 2^cost times. That makes each hash slow to compute, and the cost can be raised as hardware gets faster without changing the algorithm.

The output is one self-describing string, so the salt and cost are stored with the hash and need no separate column:

$2b$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy

$2b$                              prefix
10$                               cost
N9qo8uLOickgx2ZMRZoMye            salt (22 characters)
IjZAgcfl7p92ldGxad68LJZdL17lhWy   hash (31 characters)

To check a login, the server reads the prefix, cost and salt from the stored string, hashes the typed password with them and compares the two results. That is what the checker above does.

The cost is the one setting that matters. Each step doubles the time per hash, for you and for anyone trying to guess passwords from a leaked database. OWASP asks for a cost of at least 10. Above that, measure on your production hardware and pick the highest cost that keeps login fast enough under your peak load.

The tool times the hash it just made and estimates every other cost from it, so you can see the doubling on your own machine. It runs bcryptjs in JavaScript, which its authors put at about 30% slower than the native binding, so a server running native bcrypt is usually somewhat faster.

Raising the cost later is easy: after a successful login, check the cost in the stored hash (for example bcrypt.getRounds(hash) in Node or password_needs_rehash() in PHP) and store a new hash if it is below your current setting.

Only the first 72 bytes count. bcrypt silently ignores the rest of a longer password. With UTF-8, accented letters take 2 bytes and emoji 4, so the limit is often lower than 72 characters. If you must accept longer passphrases, do not pre-hash with a raw binary digest: bcrypt stops at a zero byte in many implementations. Prefer an algorithm without the limit, such as Argon2id.

Prefixes. Hashes made by PHP and Apache start with $2y$; Node, Python and Go libraries write $2b$ or $2a$. They verify each other for normal passwords. If a library rejects a prefix, changing $2y$ to $2b$ in the string is a known workaround, since the algorithm is the same. A $2x$ hash came from the old crypt_blowfish bug and should be replaced at the next login.

Do not compare hashes as strings. Two hashes of the same password differ because of the salt. Always call the library's compare or verify function.

// Node.js: npm i bcrypt (native) or bcryptjs (pure JS, same API)
import bcrypt from 'bcrypt';
const hash = await bcrypt.hash(password, 12);
const ok = await bcrypt.compare(password, hash);

# Python: pip install bcrypt
import bcrypt
hashed = bcrypt.hashpw(password.encode(), bcrypt.gensalt(rounds=12))
bcrypt.checkpw(password.encode(), hashed)

<?php
$hash = password_hash($password, PASSWORD_BCRYPT, ['cost' => 12]);  // $2y$12$...
password_verify($password, $hash);

// Go: golang.org/x/crypto/bcrypt
hash, err := bcrypt.GenerateFromPassword([]byte(password), 12)
err = bcrypt.CompareHashAndPassword(hash, []byte(password)) // nil means match

# Shell, with Apache's htpasswd (prints only the hash)
htpasswd -bnBC 12 "" 'the password' | tr -d ':\n'

Fast hashes such as MD5 and SHA-256 are the wrong tool for passwords even with a salt. They are right for checksums and signatures: use the hash generator for those. To protect a folder or a staging site with a password, the htpasswd generator writes bcrypt lines for Apache and Nginx. More security tools are in security tools on DevHunt.