› Bcrypt Hash Generator

Hash and verify passwords using bcrypt, the standard for password storage.

// status READY
// transport localhost · 0 bytes uploaded
// id 0xD405
bcrypt-hash.sh 0xD405
# bcrypt-hash.md

Why the Password Database You Leaked Might Still Be Fine — If You Used Bcrypt

In June 2012, LinkedIn suffered a breach that exposed 6.5 million password hashes. The hashes were SHA-1 — a fast, general-purpose cryptographic hash. Within 48 hours, a Russian cybercrime forum had cracked 60% of them. By 2016, the full 117 million account credential set was circulating on the dark web with most passwords recovered. The speed of SHA-1 was the direct cause: a modern GPU computes roughly 10 billion SHA-1 hashes per second, making a brute-force sweep through all common passwords, dictionary words, and their variants a matter of hours.

Bcrypt was designed specifically to prevent this scenario. Niels Provos and David Mazières published it in 1999 with an adaptive cost factor — a parameter that controls how much computational work each hash requires, and that can be increased as hardware gets faster. This is the key insight: bcrypt is designed to stay slow over time, while SHA and MD5 get faster with every hardware generation.

What Bcrypt Actually Does Inside

Bcrypt is based on the Blowfish block cipher. The hashing process has three phases:

  1. Key expansion: the password and a random 128-bit salt are used to initialize Blowfish's subkey table. The cost factor determines how many times this expensive initialization is repeated (2cost iterations). Cost 10 means 1,024 rounds; cost 12 means 4,096 rounds.
  2. Encryption: the string "OrpheanBeholderScryDoubt" is encrypted 64 times with the expanded key.
  3. Output: the 24-byte result is base64-encoded along with the cost and the salt into the 60-character bcrypt hash string — everything needed to verify the password is embedded in the hash itself.

Because the salt is embedded in the output, bcrypt inherently prevents rainbow table attacks (precomputed hash lookups). The salt ensures that two users with the same password produce different hashes — an attacker who cracks one hash gains nothing about other users with identical passwords.

The Cost Factor: Calibrating Slowness Over Time

The cost factor is the most important operational decision. Each increment doubles the computation time. Practical benchmarks on a modern server CPU (single-threaded bcrypt):

  • Cost 10: ~65–100 ms per hash. Acceptable for high-volume authentication services.
  • Cost 12: ~250–400 ms. Recommended for new systems in 2024. Increases to this level are overdue for most codebases.
  • Cost 14: ~1.0–1.6 s. Appropriate for high-security contexts where login latency is acceptable (admin panels, key derivation).
  • Cost 16+: 4+ seconds. Unusual for interactive logins; sometimes used for offline backup encryption keys.

The NIST Digital Identity Guidelines (SP 800-63B) recommend choosing a cost factor such that iteration takes at least 100 ms. The Argon2 algorithm (winner of the 2015 Password Hashing Competition) is the modern successor to bcrypt — it adds memory-hardness, which forces attackers to use RAM rather than pure compute, but bcrypt remains widely deployed and perfectly safe at cost 12+.

Bcrypt Limitations You Should Know

Bcrypt truncates passwords at 72 bytes. A password longer than 72 bytes is silently truncated before hashing — two passwords that share the first 72 bytes but differ only in the 73rd character will produce the same hash. Some implementations pre-hash with SHA-256 before bcrypt to work around this limit. If your application allows passwords longer than 72 characters, verify how your library handles this.

How to Use This Tool

  1. Hash mode: enter the plaintext password, set the cost factor (12 recommended), click Hash. Copy the output for storage in your database.
  2. Verify mode: paste an existing bcrypt hash and the plaintext to check. The tool confirms whether they match without re-hashing at a different cost.

All computation runs in your browser using bcryptjs. Your password text is never transmitted anywhere.

## man bcrypt-hash

?> Why can't I just use SHA-256 with a salt for passwords?

SHA-256 with a salt prevents rainbow table attacks, but SHA-256 is still fast — a GPU computes ~10 billion SHA-256 hashes per second. A bcrypt hash at cost 12 takes ~300 ms, meaning an attacker gets roughly 3 hashes per second per GPU instead of billions. The salt alone does not compensate for the speed gap.

?> What cost factor should I use in 2024?

Cost 12 is the current practical recommendation. Cost 10 was appropriate in 2011 when bcrypt was being widely adopted; hardware has improved by roughly a factor of 4–8 since then. The OWASP cheat sheet recommends a minimum of cost 10; cost 12 gives a comfortable safety margin. Re-hash passwords at login time if you upgrade cost — you cannot re-hash without the plaintext.

?> Does bcrypt work for encrypting data (not passwords)?

No. Bcrypt is a one-way hash function — there is no decryption operation. It is only appropriate for passwords and other secrets you need to verify but never retrieve in plaintext. For encrypting data you need to recover, use AES-256 with proper key management.

?> What is the 72-byte limit and should I worry about it?

Bcrypt silently truncates passwords at 72 bytes. For most users this is irrelevant — 72 bytes covers a 72-character ASCII password. If your application allows unusually long passwords or uses multibyte UTF-8 characters (Chinese, Arabic, emoji), a 72-byte cutoff could theoretically allow two different inputs to produce the same hash. The safe fix is to SHA-256 the password first and pass the hex output to bcrypt.