Bcrypt Hash Generator

About Bcrypt Hash Generator

How Does Bcrypt Work?

Bcrypt is built on top of the Blowfish cipher's key schedule. The core idea is a modified version called Eksblowfish ("expensive key schedule Blowfish"), which makes the key setup phase deliberately slow. For each hash operation, bcrypt generates a random 16-byte salt, then runs the expensive key setup 2^cost times to produce a 24-byte hash. The final output string encodes the algorithm version, cost factor, salt, and hash together in a single 60-character string.

Worked example: Given the plaintext "mypassword" and cost factor 10, bcrypt first generates a random salt like N9qo8uLOickgx2ZMRZoMye. It then runs the Eksblowfish key schedule 2^10 = 1,024 times, producing the hash portion IjZAgcfl7p92ldGxad68LJZdL17lhWy. The complete output is $2b$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy.

Part	Example	Meaning
Algorithm version	$2b$	Bcrypt variant (2b is the current standard)
Cost factor	$10$	2^10 = 1,024 iterations of the key schedule
Salt (22 chars)	N9qo8uLOickgx2ZMRZoMye	Random, Base64-encoded 16-byte salt
Hash (31 chars)	IjZAgcfl7p92ldGxad68LJZdL17lhWy	The resulting password hash

Because the salt is embedded in the output, there is no need to store it separately. Any bcrypt implementation can extract the salt from the hash string when verifying a password.

Choosing the Right Cost Factor

The cost factor (also called "salt rounds" or "work factor") controls how many times the Eksblowfish key schedule runs. Each increment doubles the computation time. The OWASP Password Storage Cheat Sheet recommends a minimum work factor of 10, and suggests tuning it so that hashing takes at least 250ms on your server hardware. As of 2026, cost factors of 12-14 are common for high-security applications.

Cost	Iterations	Approximate Time	Recommendation
4	16	~1ms	Too fast - only for testing
8	256	~10ms	Minimum for non-critical apps
10	1,024	~100-150ms	Standard default for most frameworks
12	4,096	~400-600ms	High-security applications
14	16,384	~2-3 seconds	Very high security (may be too slow for UX)

The goal is to make brute-force attacks impractical while keeping login times acceptable. A cost of 10 produces roughly 100-150ms per hash on typical server hardware in 2026, which is a reasonable starting point. If your server can handle the latency, 12 or higher provides a stronger margin against future GPU improvements.

Why Bcrypt Instead of SHA-256 or MD5?

Fast hash functions like SHA-256 and MD5 are designed for speed - that makes them useful for file checksums and data integrity, but dangerous for password storage. A single Nvidia RTX 4090 GPU can compute roughly 164 billion MD5 hashes per second according to Hashcat v6.2.6 benchmarks. The same GPU manages only about 14,000 bcrypt hashes per second at default cost, and that number halves with each cost factor increment. That difference is exactly the point.

Algorithm	RTX 4090 Speed	Built-in Salt	Adjustable Cost	For Passwords?
MD5	~164 billion/sec	No	No	No - trivially crackable
SHA-256	~22 billion/sec	No	No	No - too fast
Bcrypt	~14K/sec	Yes	Yes (cost factor)	Yes - industry standard
Scrypt	Slow + memory-hard	Yes	Yes (N, r, p)	Yes - resists GPU attacks
Argon2id	Slow + memory-hard	Yes	Yes (time, memory, threads)	Yes - PHC winner (2015)

For file checksums, digital signatures, or data integrity verification, the Hash Generator supports SHA-256, SHA-512, and MD5. Those algorithms are the right tool for that job - just never for password storage.

Bcrypt vs Argon2 vs Scrypt

Argon2id won the Password Hashing Competition in July 2015, beating 23 other candidates. It was designed by Alex Biryukov, Daniel Dinu, and Dmitry Khovratovich at the University of Luxembourg. The OWASP Password Storage Cheat Sheet (as of 2026) recommends Argon2id as the top choice for new systems, with bcrypt as a solid alternative where Argon2 is not available.

The main advantage of Argon2id and scrypt over bcrypt is memory hardness. Bcrypt is CPU-hard but requires only about 4 KB of memory, meaning attackers can run many parallel instances on GPUs or ASICs. Argon2id can require 64 MB or more of RAM per hash, making parallel attacks on GPUs far more expensive. For new projects where the language ecosystem supports Argon2, it is the stronger choice. For existing systems already using bcrypt with a cost factor of 10 or higher, bcrypt remains safe and there is no urgent need to migrate.

The 72-Byte Input Limit

Bcrypt only processes the first 72 bytes of a password. Any characters beyond that limit are silently ignored, meaning two passwords that differ only after the 72nd byte produce identical hashes. For ASCII text, 72 bytes equals 72 characters. For multi-byte encodings like UTF-8, emoji or accented characters can use 2-4 bytes each, so the effective character limit may be lower.

In October 2024, Okta disclosed a vulnerability in its AD/LDAP Delegated Authentication system caused by this limit. Okta was hashing a combined string of userId + username + password with bcrypt. When usernames exceeded 52 characters, the password portion was truncated or excluded entirely, allowing authentication bypass from a cached key. Okta switched to PBKDF2 for its cache key generation as a fix.

For most real-world passwords (typically under 30 characters), the 72-byte limit is not a practical concern. Some systems pre-hash the password with SHA-256 before passing it to bcrypt, but this approach requires careful handling of null bytes in the SHA output.

Bcrypt in Different Languages

Language	Library	Hash Example
Node.js	bcrypt or bcryptjs	bcrypt.hash(password, 10)
Python	bcrypt (pip install bcrypt)	bcrypt.hashpw(password, bcrypt.gensalt(rounds=10))
Ruby (Rails)	bcrypt-ruby (has_secure_password)	BCrypt::Password.create(password, cost: 10)
PHP	Built-in password_hash()	password_hash($password, PASSWORD_BCRYPT)
Java	Spring Security BCryptPasswordEncoder	new BCryptPasswordEncoder(10).encode(password)
Go	golang.org/x/crypto/bcrypt	bcrypt.GenerateFromPassword([]byte(pw), 10)

Node.js has two popular packages: bcrypt (native C++ binding, faster) and bcryptjs (pure JavaScript, no compilation needed). This tool uses bcryptjs because it runs in the browser without native dependencies. For server-side Node.js, the native bcrypt package is typically faster and recommended by OWASP for production use. In either case, always use the async API (hash and compare) rather than hashSync/compareSync to avoid blocking the event loop.

Bcrypt Version History

Version	Prefix	Notes
Original	$2$	Original 1999 implementation by Provos and Mazieres
2a	$2a$	Fixed UTF-8 handling issues
2b	$2b$	Current standard - fixes an unsigned char bug in OpenBSD
2y	$2y$	PHP-specific fix for 2a, functionally equivalent to 2b

All versions are compatible for verification - a hash generated with $2a$ can be verified by a $2b$ implementation. Use $2b$ for all new hashes. The bcryptjs library used by this tool defaults to $2a$ output, which is accepted by every modern bcrypt implementation.

When Should You Migrate Away from Bcrypt?

Bcrypt is not broken, but newer algorithms do offer advantages. If your system already uses bcrypt at cost factor 10 or higher, there is no urgent security need to switch. Migration typically makes sense when building a new system from scratch (where Argon2id is the better default), when your threat model includes well-funded attackers with custom ASIC hardware (memory-hard algorithms like Argon2 and scrypt raise the cost significantly), or when you need to hash inputs longer than 72 bytes without pre-hashing. The practical migration path is to re-hash passwords transparently on successful login: verify the old bcrypt hash, then store a new Argon2 hash in its place. Over time, all active users get migrated without any disruption.

Common Mistakes When Using Bcrypt

Several implementation errors come up regularly in security audits and vulnerability disclosures:

Using hashSync on the server. The synchronous bcrypt API blocks the main thread for the entire hash duration. At cost factor 12, that is 400-600ms of blocked I/O per login request. Always use the async hash() and compare() functions.

Cost factor too low. Some legacy codebases still use cost factor 4 or 6, which were already too fast on 2010 hardware. At cost factor 6, an RTX 4090 can test millions of candidates per second. Start at 10 and increase when your hardware allows it.

Storing the salt separately. Bcrypt embeds the salt in the hash string. Storing it in a separate database column is unnecessary and can lead to mismatches if the two get out of sync.

Not validating the hash format on input. When accepting a hash for verification (such as from a database or user input), check that it starts with a valid prefix ($2a$, $2b$, or $2y$) and is 60 characters long before passing it to the compare function.

To generate strong passwords before hashing, the Password Generator creates random strings at configurable lengths. To estimate how long a given password would resist a brute-force attack, the Password Strength Analyzer provides crack time estimates based on current hardware benchmarks.

Sources

• Provos & Mazieres - A Future-Adaptable Password Scheme (original bcrypt paper, USENIX 1999)
• OWASP - Password Storage Cheat Sheet
• NIST SP 800-63B - Digital Identity Guidelines: Authentication
• RFC 9106 - Argon2 Memory-Hard Function for Password Hashing
• node.bcrypt.js - Reference JavaScript bcrypt implementation
• Wikipedia - bcrypt algorithm history and version prefixes