Bcrypt Generator

Bcrypt is a password hashing function originally designed by Niels Provos and David Mazières in 1999, based on the Blowfish cipher. Unlike general-purpose cryptographic hash functions such as SHA-256 or MD5, bcrypt was engineered specifically for securely storing passwords. Its most important properties are that it is slow by design, adaptive, and incorporates automatic salting — all of which dramatically reduce the effectiveness of brute-force and dictionary attacks.

When a user registers or changes their password on a website or application, the system should never store the plaintext password directly. Instead, the password is run through bcrypt to produce a fixed-length hash string. Only this hash is stored in the database. When the user logs in again, the same process is applied to the submitted password and the resulting hash is compared to the stored one. If they match, authentication succeeds — and the original password is never exposed, even to the application itself.

The practical importance of bcrypt cannot be overstated. Data breaches exposing user credentials are common, and weakly hashed passwords — or plaintext passwords — can be cracked almost instantly with modern hardware and rainbow table databases. Bcrypt's built-in salt eliminates rainbow table attacks, while its tunable cost factor means even direct brute-force attacks require significant time per guess, even on GPUs. This makes bcrypt one of the most trusted password hashing strategies in production systems today and a staple recommendation in security guidelines from OWASP and NIST.

This bcrypt generator lets you explore how bcrypt hashes are structured, experiment with different cost factors (salt rounds), and validate hash format strings — all directly in your browser, no server required.

Bcrypt operates through a multi-stage process that combines a randomly generated salt, your input password, and a configurable cost factor to produce a 60-character output string. Understanding each stage helps you make informed decisions about cost factors and integration patterns.

Stage 1 — Salt generation: A 16-byte (128-bit) cryptographically random salt is generated for every hash operation. This salt is encoded in a modified base64 alphabet consisting of the characters A-Z, a-z, 0-9, ., and /, producing a 22-character salt string. Because each password gets a unique salt, two identical passwords will always produce completely different hashes, defeating precomputed attack databases.

Stage 2 — Key schedule expansion: The Eksblowfish (Expensive Key Schedule Blowfish) algorithm is initialized with both the salt and the password. The cost factor c controls how many times the key schedule is expanded: exactly 2^c iterations are performed. At cost 10, that is 1,024 iterations; at cost 12 it is 4,096; at cost 14 it is 16,384. Each doubling of the cost factor doubles the computation time, making brute-force attacks proportionally harder as you increase the cost.

Stage 3 — Hash output: A fixed magic string "OrpheanBeholderScryDoubt" is encrypted 64 times using the expanded key schedule. The result is base64-encoded and appended to the salt to form the final hash string. The entire output is always exactly 60 characters long in the standard Modular Crypt Format.

The salt rounds value — also called the cost factor or work factor — is the single most important tuning knob when using bcrypt. It is an integer between 4 and 31, and it controls how computationally expensive hashing is: each increment doubles the number of Eksblowfish iterations performed, which directly doubles the time required to compute a hash.

The OWASP Password Storage Cheat Sheet recommends a minimum cost factor of 10 for bcrypt and suggests reassessing the cost factor periodically as hardware improves. A good rule of thumb is to target a hashing time of approximately 100–300 milliseconds for interactive logins. For batch operations or background tasks where latency is less critical, higher cost factors provide stronger protection with no user-visible penalty.

Never use cost 4 in production. While it is useful for speeding up automated tests, the resulting hashes provide minimal protection. Conversely, cost factors above 14 can cause timeouts on resource-constrained servers and dramatically increase server load during traffic spikes — always load-test before deploying a high cost factor in a high-concurrency environment.

Every bcrypt hash is a self-contained string in the Modular Crypt Format (MCF). Unlike some hash formats that require storing the salt and parameters separately, bcrypt embeds all the information needed for verification directly into the 60-character output string. This design makes storage and comparison straightforward: just store the full hash string and compare it during login.

A valid bcrypt hash looks like: $2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy

• $2a$ — The algorithm version prefix. $2a$ is the most common and indicates bcrypt with proper UTF-8 password handling. You may also see $2b$ (corrected version used by newer implementations) or $2y$ (PHP's variant). All are functionally equivalent for most passwords.
• 10$ — The cost factor, always two digits. This tells the verifier how many iterations to use when re-hashing the supplied password for comparison. Without this, stored hashes could not be verified.
• Next 22 characters — The base64-encoded random salt. Each password gets a completely unique salt, so even if two users share the same password, their hashes will be different.
• Final 31 characters — The base64-encoded hash output derived from running the Eksblowfish cipher over the password and salt.

The bcrypt base64 alphabet differs from standard Base64. It uses ./ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789 — note the period and slash at the start — rather than the +/ of standard Base64. This is a historical artifact of the original Unix crypt implementation and has no security impact, but it means bcrypt hashes are not directly usable with standard Base64 decoders.

The verification regex used by this tool checks for this exact structure: the string must begin with $2, optionally followed by a, b, or y, then $, exactly two digits for the cost, $, and exactly 53 characters drawn from the bcrypt base64 alphabet (22 salt + 31 hash). Any deviation from this pattern indicates an invalid or malformed hash.

Implementing bcrypt correctly is straightforward, but several common mistakes can undermine its security. Following these best practices ensures your password storage is as robust as possible in production systems.

Always hash on the server side. Bcrypt password hashing must be performed on your server — never in the browser for production use. Client-side hashing could expose your hashing implementation, allow manipulation of the hash before storage, and remove bcrypt's timing attack protections. This tool is strictly for education, format exploration, and demonstration.

Never truncate passwords before hashing. Bcrypt implementations typically truncate passwords at 72 bytes (not characters). This means extremely long passwords provide no additional security beyond their first 72 bytes. If your application must accept very long passwords, consider pre-hashing with SHA-256 and encoding as hex before passing to bcrypt — but this pattern requires care to avoid introducing new vulnerabilities.

Store only the full hash string. The 60-character bcrypt output already contains the algorithm, cost, salt, and hash — never store these separately. Storing the full string simplifies verification and enables seamless cost factor upgrades (rehash on next successful login).

Use a maintained bcrypt library. Popular options include bcrypt and bcryptjs for Node.js, passlib for Python, spring-security-crypto for Java, and the built-in password_hash() / password_verify() functions in PHP 5.5+. Never implement bcrypt from scratch in production.

Plan for cost factor upgrades. Hardware gets faster every year, so a cost of 10 today may be insufficient in five years. Build in a mechanism to rehash passwords on successful login when the stored cost factor falls below your current minimum. This is transparent to users and keeps stored hashes up to date.

Bcrypt is not the only modern password hashing algorithm, and understanding how it compares to alternatives helps you choose the right tool for your security requirements.

Argon2 is the winner of the Password Hashing Competition (2015) and is now recommended by OWASP as the first choice for new applications. Unlike bcrypt, Argon2 allows you to tune not just CPU cost but also memory usage and parallelism. This makes it significantly harder to accelerate on GPUs or custom ASIC hardware, because high memory requirements limit the number of parallel guesses attackers can run simultaneously. Argon2id (the hybrid variant) is the recommended default. If you are building a new system today, prefer Argon2id where library support is available.

scrypt was designed by Colin Percival specifically to be memory-hard, predating Argon2. It offers configurable CPU and memory cost but has a more complex parameter space. scrypt is a reasonable choice and is used in several cryptocurrency and encryption applications, but its API can be harder to tune correctly compared to Argon2.

PBKDF2 is widely standardized (NIST SP 800-132, PKCS#5) and uses a HMAC function iterated many times. Its main weakness compared to bcrypt and Argon2 is that it is not memory-hard, making it significantly more vulnerable to GPU-accelerated attacks. PBKDF2 remains acceptable when compliance with FIPS standards is required, but should use a high iteration count (600,000+ for PBKDF2-HMAC-SHA256 per 2023 OWASP guidance).

MD5 and SHA-1/256 are not password hashing functions and should never be used to hash passwords, even with a salt. They are designed to be fast, making them ideal for data integrity but catastrophically easy to brute-force for passwords. Billions of password guesses per second are possible on a single GPU.

For most existing applications already using bcrypt, there is no urgent need to migrate — bcrypt remains secure when used with cost ≥ 10. For new projects, Argon2id is the modern best practice.