Bcrypt Generator

Generate cryptographically strong bcrypt hashes from any password. Choose cost factor (salt rounds), verify existing hashes, and learn why bcrypt remains the industry standard for password storage. No logs, all in your browser.

10
≈ 0.1 s (est.)
? password123
? xkcd classic
? strong mixed
⚠️ weak (demo)
? 中文密码
Verify a password against a bcrypt hash
Zero-trust privacy: Bcrypt hashing runs entirely in your browser using a pure JS implementation. No password or hash is ever sent to our server.

What is Bcrypt and Why Is It Essential?

Bcrypt is an adaptive cryptographic hash function designed for password hashing by Niels Provos and David Mazières in 1999. It is based on the Blowfish cipher and incorporates a salt to protect against rainbow table attacks, and a cost factor (work factor) to deliberately slow down the hash computation, making brute‑force attacks exponentially harder.

Bcrypt structure: $2b$[cost]$[22‑character salt][31‑character hash]

Example: $2a$10$N9qo8uLOickgx2ZMRZoMy.Mr/.PpE1xLZw5oV1Vm4pKtYdQ1N1S/q

  • $2a$ – version identifier (2a, 2b, 2y are mostly compatible; this tool uses 2a)
  • 10 – cost factor (210 = 1024 iterations)
  • 22 character salt – Radix‑64 encoded 16‑byte salt
  • 31 character hash – final 24‑byte hash (184 bits)

Historical Significance & Security Evolution

Before bcrypt, many systems stored passwords as plain MD5 or SHA‑1, often without salt. This made them extremely vulnerable to precomputed rainbow tables. Bcrypt introduced three revolutionary ideas: (1) built‑in salt, (2) adaptive cost (can be increased as hardware gets faster), and (3) resistance to GPU/FPGA cracking due to its memory‑hard and sequential nature. In 2023, NIST SP 800‑63B still recommends bcrypt (with cost ≥10) as one of the approved password storage schemes.

Why Use an Interactive Bcrypt Generator?

  • Developer Education: See exactly how a password transforms into a hash with different cost factors.
  • Testing & Debugging: Quickly generate hashes for dummy user accounts in development or staging databases.
  • Security Awareness: Observe how even a tiny change in password completely changes the hash (avalanche effect).
  • Migration & Verification: Verify that legacy passwords match their bcrypt hashes when migrating user databases.

Cost Factor Performance 

Rounds Iterations (2^rounds) Time (est.) Security Level Use Case
4 16 <1ms ❌ Critical Never use
6 64 2ms ❌ Insecure Testing only
8 256 8ms ⚠️ Weak Legacy systems
10 1,024 40ms ⚠️ Minimal High-traffic APIs
12 4,096 250ms ✅ Recommended General use
14 16,384 1.0s ✅ Strong Admin, sensitive
16 65,536 4.2s ? Very Strong High-security
18+ 262k+ 17s+ ⚠️ Overkill Impractical
Hardware note: Times are estimates on modern CPU (2026). GPU/FPGA can be 10-100x faster. Always add rate limiting.

Mathematical Foundation & Algorithm Outline

Bcrypt derives from the Blowfish cipher key schedule. The password is used to encrypt the string "OrpheanBeholderScryDoubt" (24 bytes) 64 times. The salt modifies the E‑boxes of Blowfish. The cost parameter c determines the number of key expansion iterations: 2c rounds. This exponential slowdown ensures that increasing cost by 1 doubles the computation time. The final hash is the Base64 encoding of the 24‑byte ciphertext plus the salt and cost header.

From a developer perspective, you don't need to implement the algorithm yourself – robust libraries exist in all languages. Our tool uses the well‑audited bcrypt.js library, which faithfully implements the same algorithm as OpenBSD's original.

Step‑by‑Step Hashing Process

  1. Generate a random salt – 16 bytes (128 bits) of cryptographic randomness.
  2. Encode salt in Radix‑64 (22 characters).
  3. Initialize Blowfish state with the salt and cost (iterations).
  4. Expand the password repeatedly (2cost times) to derive keys.
  5. Encrypt the 24‑byte plaintext using the final Blowfish state.
  6. Format output: version + cost + salt + hash (all Radix‑64).

Cost Factor Deep Dive: Security vs. Performance

Estimated hash times on a modern server (single core).

Cost (2n rounds) Approximate time Use case / recommendation
4 – 6 < 0.01 s Not recommended – too fast for modern hardware (legacy systems)
8 – 9 ~0.02 – 0.05 s Minimal acceptable for low‑security internal tools
10 – 12 ~0.1 – 0.4 s Recommended for most web applications (good balance)
13 – 14 ~0.8 – 1.6 s High‑security financial or master passwords
15 – 16 ~3 – 12 s Overkill for interactive login; may be used for password derivation
Case Study: SocialApp User Database Migration

A startup originally stored user passwords as salted SHA‑256. After a security audit, they decided to migrate to bcrypt. Using our tool, the team generated bcrypt hashes for a set of test passwords (cost 12) to estimate the performance impact on login. They found that hash computation added ~200 ms per login, which was acceptable. They also used the verify functionality to ensure that existing passwords could be rehashed on‑the‑fly during user login, implementing a seamless upgrade. The tool helped them choose cost 12 as the sweet spot between security and user experience.

Common Misconceptions About Bcrypt

  • “Bcrypt has a maximum password length limit (72 bytes).” True – bcrypt only processes the first 72 bytes of the password. For longer passwords, pre‑hash with SHA‑256 (but be careful to avoid weakening).
  • “Higher cost is always better.” Not exactly. Cost must be balanced against server CPU load. Setting cost too high can lead to denial of service or poor user experience.
  • “Bcrypt is outdated; we should use Argon2.” Argon2 (winner of PHC) is newer and more memory‑hard, but bcrypt remains widely used and secure when properly configured. Many standards still accept bcrypt.
  • “The salt is secret.” No, the salt is stored with the hash and is not a secret; its purpose is to make each hash unique.

Bcrypt Variants: $2a$, $2b$, $2y$, $2x$

Early implementations had minor bugs. Modern libraries produce $2b$ (OpenBSD) or $2y$ (crypt_blowfish). Our tool generates $2a$ (compatible) which is accepted by virtually all systems. The differences are negligible for interoperability.

Developed with security research background – This tool uses the audited bcrypt.js library, which has been reviewed by the open‑source community. The interactive interface was designed by the GetZenQuery security team, with references to NIST guidelines and OWASP cheat sheets. We continuously monitor cryptographic recommendations. Last reviewed: March 2026.

Frequently Asked Questions

Yes, with cost ≥10, bcrypt remains a solid choice. However, for new systems, Argon2id is recommended by OWASP. But bcrypt is not broken and is still used by many major platforms (e.g., WordPress).

No. Bcrypt is a one‑way function. The only way to "reverse" it is to try many passwords (brute‑force) and see if they match. That’s why using a strong password and sufficient cost is vital.

Both are key derivation functions. Bcrypt uses the Blowfish cipher and is more resistant to GPU cracking because of its memory‑hardness (though less than Argon2). PBKDF2 is simpler but can be efficiently attacked with ASICs. Bcrypt is generally preferred for password hashing.

Start with cost 10 on your hardware, measure the time, and adjust. Aim for ~250 ms per hash. If your server is fast, cost 12 is common. Never go below 8 in production.

Absolutely not. The hashing happens locally in your browser. We don't have a server that receives your input. You can even disconnect from the internet after loading the page.

References: Original bcrypt paper (Provos, Mazières 1999); OWASP Password Storage; NIST SP 800‑63B.