Bcrypt password generator

Bcrypt is a password hashing scheme designed specifically for securely storing passwords. Unlike general-purpose hash functions such as MD5 or SHA-256, Bcrypt is intentionally computationally expensive, making large-scale offline password guessing attacks more difficult.

What Is Bcrypt?

Bcrypt is a password hashing scheme based on the Blowfish block cipher and its intentionally expensive key schedule. It was designed by Niels Provos and David Mazières for password storage and was introduced in the context of OpenBSD.

The important characteristic of Bcrypt is that it is deliberately expensive to compute. Its work factor, also called the cost factor, can be increased as hardware becomes faster. This makes password guessing more expensive for an attacker while allowing legitimate applications to adjust the computational cost over time.

How Does Bcrypt Work?

Bcrypt combines a password, a cryptographically random salt, and a configurable cost factor to produce a password hash. The resulting Bcrypt string contains the information needed for verification, including the algorithm identifier, cost, salt, and derived password value.

This means an application does not need to store the salt or cost factor separately when using a standard Bcrypt password-hash format.

Bcrypt Password Hash Format Explained

A Bcrypt password hash is a structured string rather than simply a random sequence of characters. A common modern example is:

$2b$12$FPWWO2RJ3CK4FINTw0Hi8OiPKJcX653gzSS.jqltHFMxyDmmQ0Hqq

The string contains a version identifier, a two-digit cost factor, a 128-bit salt, and the Bcrypt derived value. The salt and derived value use Bcrypt's own Radix-64-style encoding rather than standard RFC 4648 Base64.

Why Does Bcrypt Have So Many Prefixes?

One of the most confusing aspects of Bcrypt is that the beginning of a password hash may be $2$, $2a$, $2b$, $2x$, or $2y$.

These prefixes are not a ranking from weak to strong. They are primarily version and compatibility identifiers introduced because the historical Bcrypt ecosystem contained specification changes and implementation-specific bugs.

In particular, $2x$ and $2y$ were introduced by the crypt_blowfish implementation after a bug involving 8-bit characters was discovered. They are not "stronger versions" of Bcrypt.

Bcrypt Prefix History at a Glance

The Important Relationship Between the Prefixes

Why Was $2x$ Created?

In 2011, a bug was discovered in the crypt_blowfish implementation of Bcrypt. The implementation incorrectly handled certain characters with the high bit set, such as some 8-bit/non-ASCII byte values.

The compatibility solution was to distinguish hashes produced using the broken behavior from hashes produced using the corrected behavior. The $2x$ identifier represents the old buggy behavior, while $2y$ represents the corrected behavior.

This is why you should never blindly replace every $2a$ prefix with $2x$. A $2a$ hash does not automatically mean that the buggy behavior was used.

What Is the Bcrypt Cost Factor?

The Bcrypt cost factor controls the computational work required by the algorithm. It is sometimes informally called the number of "rounds", but that description can be misleading.

The cost parameter is logarithmic. Increasing the cost by one approximately doubles the computational work. The work therefore scales approximately as 2cost.

There is no universal cost value that is optimal for every server. A practical approach is to benchmark the production environment and select the highest cost that provides acceptable authentication latency while still leaving sufficient capacity for legitimate login traffic.

The cost should be reviewed periodically as hardware performance improves. Existing passwords can normally be migrated to a higher cost gradually during successful login operations.

What Is a Bcrypt Salt?

A salt is a random value generated for a password before the Bcrypt computation. Using a different salt for each password means that two users with the same password will normally have different Bcrypt hashes.

Is Bcrypt Encryption or Hashing?

Bcrypt is a password hashing scheme, not an encryption algorithm. This distinction is important.

Bcrypt 72-Byte Password Limit

72 Bytes Is Not 72 Characters

Bcrypt and NUL Bytes

Bcrypt has historical string-handling semantics involving the terminating NUL byte (\0). This becomes especially important when developers attempt to pre-hash passwords with a binary hash function and then feed the raw binary output into Bcrypt.

bcrypt(SHA-256(password))

What Do $2a$, $2b$, $2x$ and $2y$ Mean?

You may encounter different Bcrypt prefixes when working with existing password databases. These identifiers are primarily related to historical implementations, compatibility, and bug fixes. They should not be interpreted as a simple ranking from "weak" to "strong".

Bcrypt Prefixes in PHP

PHP is particularly relevant to the $2x$ and $2y$ history because PHP's password hashing ecosystem used the crypt_blowfish implementation involved in the 2011 bug.

In modern PHP, PASSWORD_BCRYPT generates a standard crypt()-compatible Bcrypt hash using the $2y$ identifier.

$2y$12$...

Therefore, if a PHP application generates a Bcrypt password with password_hash($password, PASSWORD_BCRYPT), seeing $2y$ is expected.

PHP's PASSWORD_DEFAULT currently uses Bcrypt, but that constant is intentionally designed to change in the future if PHP adopts a stronger default. Applications should therefore use a database column capable of storing hashes longer than the current 60-character Bcrypt output; PHP recommends a column capable of storing up to 255 characters.

Is Bcrypt Secure?

Bcrypt remains a well-established and widely supported password hashing algorithm. Its primary security benefit is that it makes offline password guessing substantially more expensive than using fast general-purpose hash functions.

However, Bcrypt does not make weak passwords unbreakable. If an attacker obtains a database of password hashes, they can attempt password guesses offline.

For new password-storage systems, Argon2id is generally preferred because it is memory-hard and provides better resistance against attackers who can use highly parallel hardware. Bcrypt remains particularly useful for existing systems, compatibility requirements, and platforms where Argon2id is unavailable.

Bcrypt Password Hashing Best Practices

Password Length and Password Policy

Password hashing and password policy solve different problems. Bcrypt protects stored passwords against offline guessing, while password policy determines which passwords users are allowed to choose.

Modern password guidance generally favors allowing long passwords and passphrases instead of imposing arbitrary composition rules such as requiring a mixture of uppercase letters, lowercase letters, numbers, and special characters.

Applications should also consider blocking passwords that are known to have been compromised in previous data breaches or are otherwise extremely common.

Bcrypt vs Argon2id

Bcrypt is still useful, especially when compatibility and broad library support are important. For a new application, however, it is generally preferable to evaluate Argon2id, a modern memory-hard password hashing algorithm.

What Is a Password Pepper?

A pepper is an optional application-level secret that is combined with a password before or during password hashing. Unlike a salt, a pepper is intended to remain secret and should be stored separately from the password database, for example in a dedicated secrets-management system.

A pepper can provide additional defense in depth if an attacker obtains only the password database. However, it does not replace a proper password hashing algorithm, a unique salt, or good password security practices.

How to Use the Bcrypt Password Generator

The Bcrypt Password Generator above can be used to generate Bcrypt password hashes for development, testing, and educational purposes. Enter a test password, choose a cost factor, and generate the resulting Bcrypt hash.

How to Verify a Bcrypt Password

Applications should not decrypt or reverse a Bcrypt hash because Bcrypt is not an encryption algorithm. During login, the application takes the password supplied by the user, reads the parameters stored in the Bcrypt hash, performs the appropriate Bcrypt computation, and uses the password verification API to determine whether the password matches.

Do not implement password verification by manually manipulating the Bcrypt string or by replacing its prefix. Use the password verification function supplied by the language or framework.

PHP Bcrypt Verification Example

PHP provides dedicated APIs for password hashing and verification. A typical Bcrypt workflow is to generate the hash with password_hash(), verify it with password_verify(), and check whether it needs to be regenerated with password_needs_rehash().

<?php $password = $_POST['password']; $hash = password_hash($password, PASSWORD_BCRYPT, [ 'cost' => 12 ]); if (password_verify($password, $hash)) { echo 'Password is valid'; } ?>

Bcrypt Password Rehashing

Password hashing parameters may need to be strengthened over time. A common migration strategy is to verify the user's existing password during login and, when the password is successfully authenticated using an older configuration, generate a new hash using the current recommended parameters.

PHP Rehashing Example

<?php $storedHash = $user['password_hash']; $password = $_POST['password']; $options = [ 'cost' => 12 ]; if (password_verify($password, $storedHash)) { if (password_needs_rehash( $storedHash, PASSWORD_BCRYPT, $options )) { $newHash = password_hash( $password, PASSWORD_BCRYPT, $options ); // Store $newHash in the database. } // Login successful. } ?>

Migrating Legacy Bcrypt Passwords

Legacy databases may contain $2$, $2a$, $2x$, $2y$, or $2b$ hashes depending on which implementation and version generated them.

The safest migration strategy is generally verify first, then rehash. The application should identify which legacy formats its password library supports and use the library's documented compatibility behavior.

Bcrypt Prefix Comparison

Bcrypt Security Limitations

Bcrypt is not a magic solution for password security. Its effectiveness depends on correct implementation, appropriate cost configuration, strong user passwords, and secure application architecture.

Conclusion

Bcrypt was designed specifically for password storage and remains a widely supported password hashing option. Its use of a random salt and adjustable computational cost makes offline password guessing significantly more expensive than when using fast, general-purpose hash functions.

Bcrypt is not encryption, it does not make weak passwords impossible to guess, and it has important implementation details such as its 72-byte password input limitation. Applications should also understand the historical $2$, $2a$, $2x$, $2y$, and $2b$ identifiers when working with legacy password databases.

The different prefixes are primarily historical compatibility markers rather than a simple security ranking. In particular, $2x$ identifies the historical buggy crypt_blowfish behavior, while $2y$ identifies its corrected behavior. $2b$ was introduced by OpenBSD for a separate password-length handling bug.

For new applications, modern password hashing schemes such as Argon2id should generally be preferred. For existing applications, a properly configured Bcrypt implementation, a suitable cost factor, secure password verification, and gradual rehashing can provide a strong password storage strategy.