Bcrypt Hash Generator

Bcrypt Generator: Free Online Password Hashing Tool for Secure Development and Testing

Bcrypt is the gold standard of password hashing algorithms for web applications. Designed in 1999 by Niels Provos and David Mazières, bcrypt has remained one of the most trusted password hashing functions in existence "” surviving decades of cryptanalytic scrutiny while MD5, SHA-1, and even SHA-256 (when used directly for passwords) have been rendered dangerously inadequate. Our free online bcrypt generator lets you hash passwords and verify bcrypt hashes instantly in your browser, with configurable work factors, for development, testing, and learning purposes.

This tool is designed for developers implementing authentication systems, security engineers auditing password storage practices, students learning about cryptographic hashing, and anyone who needs to generate bcrypt hashes for testing or seeding databases without writing code. All computation runs in your browser "” no passwords are transmitted to our servers.

Why Password Hashing Is Not Like Regular Hashing

A fundamental misconception in web development is treating password storage like any other data hashing problem. General-purpose cryptographic hash functions (MD5, SHA-1, SHA-256) are designed to be fast "” they can hash gigabytes of data per second, which is essential for their intended applications: file integrity checking, digital signatures, and message authentication.

For passwords, speed is the enemy. The faster a hash function runs, the more passwords an attacker can test per second in a brute-force or dictionary attack. A modern GPU can compute billions of SHA-256 hashes per second. Given that most user passwords are short and drawn from a limited vocabulary of common words, phrases, and patterns, an attacker with a stolen SHA-256 password database can crack the majority of accounts in hours.

Password hashing functions are designed with the opposite goal: they must be deliberately slow. Bcrypt's work factor (cost factor) controls how many iterations of the core algorithm execute, letting you tune the hashing time from milliseconds to seconds. A legitimate login attempt waiting 200ms for password verification is imperceptible to users. An attacker testing a billion password candidates at 200ms each would need 6,000 years.

How Bcrypt Works: The Blowfish Key Setup

Bcrypt is based on the Blowfish block cipher. Specifically, it uses an expensive key schedule algorithm from Blowfish called EksBlowfishSetup. The name bcrypt comes from "b" for Blowfish and "crypt" from the Unix password hashing API.

The bcrypt algorithm:

• Generates a random 128-bit (16-byte) salt: each password hash gets its own unique random salt, making precomputed rainbow table attacks impossible even if the attacker knows the hashing algorithm.
• Runs EksBlowfishSetup: initializes the Blowfish cipher state using the cost factor, salt, and password. This step is intentionally expensive "” it runs 2^cost_factor iterations of the Blowfish key schedule, where each iteration is computationally intensive.
• Encrypts the OrpheanBeholder string: a specific 192-bit constant ("OrpheanBeholderScryDoubt") is encrypted 64 times with the initialized cipher.
• Produces the final hash: the output combines the cost factor, salt, and ciphertext in a standard format.

The entire bcrypt hash is self-contained: $2b$12$LQv3c1yqBWVHxkd0LHAkCOYz6TtxMQJqhN8/LewdBPj/VPLMsAbBK

Breaking this down:

• $2b$ "” version identifier (2b is the current recommended version; 2a and 2y also exist)
• 12$ "” cost factor (12 means 2^12 = 4,096 iterations)
• Next 22 characters "” Base64-encoded 128-bit salt
• Remaining 31 characters "” Base64-encoded 184-bit hash output

Total: 60 characters for the complete bcrypt hash including the version, cost, salt, and checksum "” everything needed to verify a password is in the hash itself.

Bcrypt Work Factor: Choosing the Right Cost

The work factor (cost factor) is bcrypt's most important configuration parameter. It determines how many iterations of the key schedule run: 2^cost iterations. Each increment of the cost factor doubles the computation time.

Current Recommendations (2024)

OWASP (Open Web Application Security Project) recommends a minimum work factor of 10 for bcrypt, with 12 preferred when the hardware budget allows. The goal is for password hashing to take approximately 100-300 milliseconds on current hardware for a single hash.

Typical bcrypt timing on modern server hardware (2024):

• Cost 10: ~65ms per hash
• Cost 11: ~130ms per hash
• Cost 12: ~260ms per hash (OWASP preferred)
• Cost 13: ~520ms per hash
• Cost 14: ~1040ms per hash (one second "” noticeable to users)

For high-traffic applications where authentication is a bottleneck, cost 10 or 11 is a practical balance. For low-traffic security-sensitive applications (admin portals, financial systems), cost 12 or 13 provides stronger protection.

Increasing Cost Over Time

One of bcrypt's elegant properties is that you can increase the work factor over time as hardware gets faster. During login, after successfully verifying the password against the current hash, rehash the password with the new higher cost factor and update the stored hash. Users transparently get upgraded security at their next login without any disruption.

Bcrypt Salting: Preventing Rainbow Table Attacks

Every bcrypt hash includes a unique 128-bit random salt generated during hashing. This salt is incorporated into the key setup, meaning two users with identical passwords will have completely different bcrypt hashes.

Example: both Alice and Bob use the password "password123"

Alice's hash: $2b$12$LQv3c1yqBWVHxkd0LHAkCOYz6TtxMQJqhN8/LewdBPj/VPLMsAbBK

Bob's hash: $2b$12$wH3PNfAbg7j2M7xA/wPkouQz1BTdcMYjWL3OYkz0YRwP8Z3eHvr0.

The salt is embedded in the hash string so verification does not require storing it separately. This means:

• Rainbow tables are useless: a precomputed rainbow table of unsalted hashes cannot crack bcrypt because each hash has a unique salt "” an attacker would need a separate rainbow table for every possible salt value.
• Credential stuffing is harder: an attacker cannot determine which users share the same password by comparing hashes "” all hashes look unique.
• Per-record cracking required: if an attacker cracks one bcrypt hash, the work provides no shortcut for cracking other hashes "” each hash must be attacked independently.

Bcrypt Versions: 2a, 2b, and 2y

The bcrypt specification has evolved through several versions:

• $2$ "” original version. Had a bug with passwords containing non-ASCII bytes. Do not use.
• $2a$ "” fixed non-ASCII bug, but some implementations (notably OpenBSD) had a different bug with passwords containing the null byte. Widely deployed but has implementation inconsistencies.
• $2b$ "” the correct, canonical version introduced in OpenBSD 5.5. All new implementations should produce $2b$ hashes. Most modern libraries (bcrypt for Node.js, Python's bcrypt, PHP 7.x+) produce $2b$ by default.
• $2x$ and $2y$ "” versions introduced by PHP to work around the $2a$ bug. $2y$ is equivalent to $2b$ in correctly-implemented bcrypt. PHP 7+ defaults to $2y$ which is verified-equivalent to $2b$.

Our generator produces $2b$ hashes "” the current standard. Verification accepts all common versions.

Bcrypt's 72-Character Password Limit

One important limitation: bcrypt silently truncates passwords to 72 bytes (not characters "” multibyte UTF-8 characters count as multiple bytes). Passwords longer than 72 bytes produce the same hash as the first 72 bytes. This has two implications:

Security implication: users who set very long passphrases (73+ characters) receive no additional security from the extra characters beyond the 72-byte limit "” the extra content is ignored.

Practical mitigation: two approaches are used in production. The safer approach is to pre-hash the password with SHA-256 or SHA-512 before passing to bcrypt "” the SHA output is always 32 or 64 bytes, well within the limit, and represents the full entropy of any-length input. The simpler approach is to limit accepted passwords to 72 bytes and clearly communicate this to users.

Our generator shows the effective byte length of your input and warns if it exceeds 72 bytes.

Bcrypt Implementation in Major Languages

Node.js / JavaScript

The bcrypt package (native binding to C++ bcrypt) and bcryptjs (pure JavaScript, no native dependencies) are both widely used:

const bcrypt = require('bcrypt');

const hash = await bcrypt.hash(password, 12); // saltRounds = cost factor

const match = await bcrypt.compare(password, hash); // returns boolean

Always use the async API (bcrypt.hash / bcrypt.compare) rather than the synchronous API (bcrypt.hashSync / bcrypt.compareSync) in Node.js servers. The sync versions block the event loop during the CPU-intensive hash computation, degrading server responsiveness for all concurrent requests.

Python

The bcrypt package wraps the OpenBSD bcrypt implementation:

import bcrypt

hashed = bcrypt.hashpw(password.encode('utf-8'), bcrypt.gensalt(rounds=12))

match = bcrypt.checkpw(password.encode('utf-8'), hashed)

Always encode the password to bytes before passing to bcrypt. The gensalt(rounds=12)call generates a new random salt with the specified cost factor "” you do not manage the salt separately.

PHP

PHP 5.5+ has native bcrypt support through password_hash() andpassword_verify():

$hash = password_hash($password, PASSWORD_BCRYPT, ['cost' => 12]);

$match = password_verify($password, $hash); // returns boolean

PHP also provides password_needs_rehash() to check if a stored hash was generated with a lower cost factor and should be upgraded on next login.

Java / Spring

Spring Security provides BCryptPasswordEncoder:

BCryptPasswordEncoder encoder = new BCryptPasswordEncoder(12);

String hash = encoder.encode(rawPassword);

boolean matches = encoder.matches(rawPassword, encodedPassword);

Go

golang.org/x/crypto/bcrypt:

hash, err := bcrypt.GenerateFromPassword([]byte(password), 12)

err := bcrypt.CompareHashAndPassword([]byte(hash), []byte(password))

Ruby / Rails

The bcrypt gem (which has_secure_password in Rails uses internally):

require 'bcrypt'; hash = BCrypt::Password.create(password, cost: 12)

BCrypt::Password.new(hash) == password # returns boolean

Bcrypt vs Argon2 vs scrypt vs PBKDF2

Bcrypt (1999)

Pros: time-tested, widely supported in every language and framework, simple configuration (one cost parameter). Cons: fixed maximum memory usage, no parallelism resistance (can be attacked with multiple GPUs/threads), 72-byte password limit. Still excellent and recommended for most web applications.

scrypt (2009)

Pros: memory-hard (requires significant RAM for computation, making GPU attacks more expensive), configurable memory and CPU cost. Cons: two-parameter tuning is error-prone, less universal library support than bcrypt. Better than bcrypt for hardening against ASIC/GPU attacks.

Argon2 (2015 "” Password Hashing Competition Winner)

The current OWASP and NIST recommendation for new applications. Three variants:

• Argon2d "” fastest, best resistance against GPU attacks, but vulnerable to side-channel attacks. Suitable for cryptocurrencies, not authentication.
• Argon2i "” side-channel resistant, weaker against GPU attacks. Suitable for password hashing.
• Argon2id "” hybrid approach (OWASP and NIST recommended). Use this unless you have a specific reason not to.

Argon2id parameters: minimum memory 19MB, minimum time cost 2, minimum parallelism 1 (OWASP minimum recommendation). Supported in Python via argon2-cffi, Node.js viaargon2, PHP via password_hash($pass, PASSWORD_ARGON2ID) (PHP 7.3+).

PBKDF2 (2000)

NIST-recommended and FIPS-compliant. The only option in some regulated environments (US government systems). Less memory-hard than bcrypt/scrypt/Argon2, making it relatively more vulnerable to GPU brute force. Requires very high iteration counts (OWASP recommends 600,000 iterations with SHA-256, 1,300,000 with SHA-1). Available natively in .NET, Java, iOS, and Android without additional libraries.

Implementing Bcrypt Correctly: Common Mistakes

Timing-Safe Comparison

Never compare bcrypt hashes with string equality (=== or ==). String comparison short-circuits as soon as it finds a mismatch, creating a timing oracle that leaks information about where hashes differ. Use the library's provided compare function, which performs constant-time comparison. All mainstream bcrypt libraries handle this correctly.

Blocking the Event Loop

The synchronous bcrypt API in Node.js blocks the entire event loop during hashing. A login endpoint using bcrypt.hashSync() will freeze all other request processing for 100-300ms per authentication. Always use the async API in server applications.

Cost Factor Too Low

Using a cost factor of 4 or 6 (often seen in tutorials that prioritize test speed) is dangerous in production. Cost 4 takes microseconds, providing essentially no protection. The code that sets the cost factor must be different between test environments (cost 4 for speed) and production (cost 12 for security). Use environment variables to configure the cost.

Storing Plaintext Passwords "Temporarily"

Never store plaintext passwords for any duration "” not in a database, not in a log, not in a temporary file, not in application memory longer than necessary. Hash on receipt, immediately, before any other processing. Treat the plaintext password like a hot coal "” handle it briefly and discard it.

Using Bcrypt for Non-Password Data

Bcrypt's intentional slowness is a feature for passwords and a bug for other use cases. Do not use bcrypt for API key verification, session token validation, file checksums, or any high- throughput hashing need. Use HMAC-SHA256 for those scenarios.

Bcrypt Hash Format Reference

A complete bcrypt hash like $2b$12$LQv3c1yqBWVHxkd0LHAkCOYz6TtxMQJqhN8/LewdBPj/VPLMsAbBK contains:

• $2b$ "” algorithm version (2b = current canonical bcrypt)
• 12$ "” cost factor (work factor = 2^12 = 4,096 iterations)
• LQv3c1yqBWVHxkd0LHAkCO "” 22 characters: Base64-encoded 128-bit salt
• Yz6TtxMQJqhN8/LewdBPj/VPLMsAbBK "” 31 characters: Base64-encoded 184-bit hash

Total length: 60 characters. Fixed, regardless of input password length. The complete hash is stored as a single string in the database "” no need to store salt separately.

The bcrypt Base64 alphabet is slightly different from standard Base64: it uses ./ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"” note the ./ at the start instead of +/.

Testing Bcrypt Hashes

During development, you often need to:

• Generate test bcrypt hashes for seed data
• Verify that a password matches a stored hash in a database
• Check that your bcrypt implementation produces hashes in the expected format
• Test that password update flows correctly replace old hashes
• Validate that the cost factor is configured correctly in different environments

Our tool supports all of these: generate a hash from a password with a chosen cost factor, verify that a password matches a given bcrypt hash, and inspect the hash structure (version, cost, salt) without writing any code.

Database Schema for Bcrypt Hashes

Store bcrypt hashes in a VARCHAR(60) column (exactly 60 characters). Some developers use CHAR(60) (fixed length). Do not truncate to fewer than 60 characters "” the hash will become unverifiable. If you are planning for potential future algorithm migration to Argon2 or similar, use VARCHAR(255) to accommodate longer future hash strings without a schema migration.

Column naming convention: password_hash or password_digest(Rails convention). Never name the column password "” this risks confusion with plaintext storage and may trigger GDPR/compliance audit flags.

Privacy: Why This Tool Never Sees Your Passwords

All bcrypt computation in our tool runs in your browser using WebAssembly. The password you type, the salt generated, and the hash produced never leave your browser. No network request is made during hashing or verification. The tool works completely offline once loaded.

This matters because: passwords are the most sensitive data users create. Even if a bcrypt hash is exposed, a strong password is safe (bcrypt's slowness protects it). But plaintext passwords transmitted to a third-party server represent an unacceptable risk even when TLS is used "” the server could log, store, or leak the plaintext. Our offline-first architecture eliminates this risk entirely.