Bcrypt Hash Generator

Bcrypt was designed by Niels Provos and David Mazieres in 1999 and published in their paper "A Future-Adaptable Password Scheme" at the USENIX Annual Technical Conference. The algorithm is based on the Blowfish block cipher, a symmetric encryption algorithm created by Bruce Schneier in 1993. Provos and Mazieres adapted Blowfish's expensive key schedule as the foundation for a password hashing function that could be tuned to become slower over time as hardware improved. This adaptive property is what makes bcrypt "future-adaptable" and is the core reason it remains relevant more than 25 years after its introduction.

The bcrypt algorithm works in three stages. First, it generates a 128-bit random salt using a cryptographically secure random number generator. Second, it derives an encryption key from the password and salt using an expensive key schedule called EksBlowfishSetup (Expensive Key Schedule Blowfish Setup). This key schedule is the computationally expensive part: it processes the password and salt through 2^cost iterations, where cost is the user-specified cost factor. Third, it uses the derived key to encrypt the 24-byte constant string "OrpheanBeholderScryDoubt" 64 times using Blowfish in ECB mode. The resulting 24-byte ciphertext (truncated to 23 bytes) is the final hash, which is then Base64-encoded and concatenated with the algorithm identifier, cost factor, and salt to form the complete hash string.

The Cost Factor: Exponential Security Scaling

The cost factor is bcrypt's most important parameter. It controls the number of iterations in the key derivation step as a power of 2. A cost factor of 10 means 1,024 iterations; 12 means 4,096 iterations; 14 means 16,384 iterations. Each increment doubles the time required to compute one hash, which directly halves the number of passwords an attacker can test per second. On a modern server CPU, a cost factor of 10 takes approximately 80-100 milliseconds per hash, while a cost factor of 12 takes 300-400 milliseconds. The OWASP Password Storage Cheat Sheet recommends choosing the highest cost factor that keeps login time under one second. For most web applications in 2026, a cost factor of 12 provides the right balance between security and user experience.

Why Not MD5 or SHA for Passwords?

General-purpose hash functions like MD5 and SHA-256 are designed to be fast. SHA-256 can compute over 20 billion hashes per second on a modern GPU. This speed is desirable for data integrity verification but catastrophic for password storage, because an attacker who obtains a database of SHA-256 password hashes can test billions of candidate passwords per second. Bcrypt with a cost factor of 12 limits the same GPU to roughly 50,000 attempts per second, a reduction by a factor of 400,000. Even with a dedicated cracking rig using multiple high-end GPUs, bcrypt makes exhaustive password searching impractical for any password with reasonable entropy. This fundamental difference between "fast" and "slow" hashing is why every modern security standard specifies a dedicated password hashing algorithm rather than a general-purpose hash.

Salting: Defeating Rainbow Tables

A salt is random data added to the password before hashing. Without a salt, identical passwords produce identical hashes, allowing attackers to use precomputed lookup tables (rainbow tables) to reverse hashes instantly. A rainbow table for all 8-character alphanumeric passwords against unsalted MD5 fits in about 460 gigabytes. With bcrypt's 128-bit salt, each password hash is unique even if two users choose the same password, making rainbow tables completely useless. The salt must be random and unique per password, but it does not need to be secret. Bcrypt handles salt generation and storage automatically, embedding the salt directly in the output hash string.

Secure password hashing is a non-negotiable requirement for any application that stores user credentials. Bcrypt remains one of the most trusted and widely deployed solutions for this critical task. Here is why developers and security engineers rely on bcrypt:

• Proven track record -- Bcrypt has been in production use since 1999 with no practical cryptographic breaks discovered. OpenBSD adopted it as the default password hash in 1997 (during its development phase), and it has since been implemented in virtually every programming language and framework: PHP's password_hash(), Python's bcrypt library, Node.js bcryptjs, Ruby's bcrypt-ruby, Java's jBCrypt, and Go's golang.org/x/crypto/bcrypt. This 25+ year track record provides confidence that no hidden vulnerabilities exist.
• Adaptive difficulty -- As hardware becomes faster, bcrypt's cost factor can be increased to maintain the same level of resistance. A system deployed with cost factor 10 in 2010 can be upgraded to cost factor 13 in 2026 to compensate for the roughly 8x improvement in GPU performance during that period. Existing password hashes do not need to be recomputed; the system simply re-hashes passwords with the new cost factor when users next log in.
• Built-in salt management -- Unlike raw SHA-256 hashing, bcrypt generates and stores its own salt automatically. This eliminates an entire class of implementation errors where developers forget to salt passwords, reuse salts, or store salts incorrectly. The self-contained hash string means a single database column stores everything needed for verification.
• Framework and library support -- Every major web framework includes bcrypt support out of the box or through a well-maintained library. Django, Rails, Laravel, Express.js, Spring Boot, and ASP.NET all provide bcrypt integration. This universal support means developers can adopt bcrypt without writing any cryptographic code themselves.
• Compliance alignment -- OWASP, NIST, and PCI-DSS all recommend or require the use of adaptive password hashing functions. Bcrypt satisfies these requirements alongside scrypt and Argon2. Using bcrypt demonstrates due diligence in security audits and simplifies compliance reporting for SOC 2, HIPAA, and ISO 27001 certifications.

Privacy and Security

This bcrypt tool runs entirely in your browser. The password you enter and the hash it produces are never transmitted to any server, stored in any database, or logged by any system. This is critical because passwords being hashed are, by definition, sensitive data. Server-side bcrypt tools require you to send your plaintext password over the network, which creates a transmission risk and requires trust in the operator. DevToolKit's client-side approach eliminates both risks entirely. The bcrypt computation runs in JavaScript using a proven implementation of the algorithm with full salt generation and cost factor support.