Bcrypt Hash Generator

Bcrypt, When and How to Use It

Storing passwords in plaintext is a critical vulnerability. So is using a fast hash like MD5 or SHA-256. Bcrypt was designed in 1999 specifically to resist both naïve attacks and the increasingly-cheap brute-force compute that breaks general-purpose hashes. Two decades later it's still a sensible default, and understanding why helps you use it correctly.

Why Fast Hashes Fail at Passwords

SHA-256 is a great hash. Computing one takes microseconds on a CPU and nanoseconds on a GPU. That's the right speed for file integrity, certificate signing, blockchain proof-of-work. It is exactly the wrong speed for passwords.

If your database leaks with SHA-256 password hashes:

• An RTX 4090 computes ~22 billion SHA-256 hashes per second.
• Trying the top 10 million passwords against 1 million accounts: ~10 minutes.
• Trying all 8-character passwords (95^8 candidates): a few days.

With Bcrypt at cost 12 (~4096 iterations, ~250ms per hash):

• One GPU manages a few thousand Bcrypt hashes per second instead of billions.
• The same attack takes ~20 years on the same hardware.
• Attackers shift to targeted attacks (specific high-value accounts) rather than mass cracking.

This 6-orders-of-magnitude difference is the entire reason password-specific hashes exist.

Key Stretching: The Core Idea

Bcrypt iterates its underlying Blowfish-based key schedule 2^cost times. Cost 10 = 1024 iterations. Cost 14 = 16384. Each increment doubles the work. The legitimate user, logging in once, pays a 200-500ms cost. The attacker, testing billions of guesses, pays it billions of times.

The "right" cost factor moves over time. Bcrypt cost 10 was fine in 2010. In 2026, with cheaper compute, 12 is the typical floor. Best practice: pick a cost that gives ~250ms per hash on your production hardware, then re-tune every couple of years.

Anatomy of a Bcrypt String

Total: 60 characters. Everything needed to verify a password is in the string:

• Version ($2b$), algorithm variant.
• Cost (12), work factor.
• Salt (next 22 chars), random 16 bytes encoded in Bcrypt-Base64.
• Hash (final 31 chars), the actual derived output.

Database design: one VARCHAR(60) column. Done. No separate salt column, no version column. If you migrate to a stronger algorithm, you can add a version prefix ($argon2id$...) and your verification code branches on the prefix.

Implementation Best Practices

1. Use a battle-tested library. Node: bcryptjs (pure JS) or bcrypt (native bindings). PHP: password_hash / password_verify. Python: bcrypt. Go: golang.org/x/crypto/bcrypt. Never write your own.
2. Set a sensible cost. Default 10 is too low for production in 2026. Aim for cost 12; benchmark on your server hardware.
3. Migrate quietly on login. When a user logs in successfully with an old-cost hash, rehash at the new cost and update the database. Six months later most active users are migrated.
4. Watch the 72-byte limit. Bcrypt silently truncates input longer than 72 bytes. If you allow long passwords, either pre-hash with SHA-256 (then Base64-encode to 44 chars) or use Argon2 which has no truncation.
5. Constant-time comparison. Library verify functions use constant-time compare. If you wrote your own (don't), use crypto.timingSafeEqual.
6. Rate-limit login attempts. Even strong hashing doesn't protect a single account from sequential guessing. Limit to ~5 attempts per minute per IP per account.
7. Pepper for defense in depth. Append an application-level secret (from env vars, not the database) to the password before hashing. If only the DB leaks, hashes stay uncrackable. If env vars also leak, you have standard hashing security.

Common Mistakes

Lowering cost because tests are slow. Tests should mock the hash function or use cost 4 in test environments. Don't lower production cost.

Hashing pre-hashed values inconsistently. If you sometimes pass SHA-256(password) and sometimes pass password, half your users can't log in. Pick one and stay consistent.

Logging the input. Login failure logs that include attempted passwords are a perpetual source of leaks. Strip passwords before logging.

Comparing hashes with ==. Timing attacks can leak partial matches. Always use the library's verify function.

Storing the cost or salt separately. Defeats the self-describing hash format. Store the full 60-char hash and parse it on verify.

Never increasing the cost. A hash generated in 2015 at cost 10 is much weaker today. Set a calendar reminder to retune.

When to Migrate to Argon2

Reasons to migrate from Bcrypt to Argon2id:

• New project (no legacy to migrate).
• High-value targets (financial, medical, government).
• You're already updating the auth stack for another reason.
• Bcrypt's 72-byte truncation bothers you.

Reasons to stay with Bcrypt:

• You've already shipped it and there are no other security issues.
• Your library ecosystem doesn't have great Argon2 support.
• Simpler operational story than tuning Argon2's three parameters.

Migration approach: on successful login with a Bcrypt hash, rehash with Argon2 and update the database. Your verify function checks the hash prefix to pick the right algorithm.

Testing and Debugging Workflows

This tool is well-suited for:

• Seed data generation. Hash a known password at cost 12, paste the result into a SQL fixture.
• Cost benchmarking. Generate at cost 10, 11, 12, 13, measure how long each takes on your laptop. Adjust production cost accordingly.
• Auth debugging. Got a 60-char string that looks like Bcrypt? Decode the version and cost, then verify against a candidate password.
• Migration verification. When changing cost factors, hash a sentinel value at the new cost; confirm the existing verify code accepts it.
• Educational exploration. Watch how doubling the cost doubles the time. Visceral demonstrations beat theory.

Privacy

This generator runs entirely in your browser using a JavaScript Bcrypt implementation. Passwords, hashes, and cost configuration never leave the page. For production password operations, integrate Bcrypt directly into your backend, but for testing, learning, and seed data, browser-side generation is the right call.

The Network tab will be empty during hash operations. If you're inspecting hashes from a real database during an incident response, browser-side analysis ensures you don't accidentally cross-contaminate the inspection environment with the production data.