What is a Bcrypt Hash Verifier?
A bcrypt hash verifier is a tool that checks whether a given plaintext password, when processed through the bcrypt algorithm, produces a hash that matches a stored hash value. It is the same operation your application performs during user login: the user enters a password, and the system calls password_verify($input, $storedHash) to confirm correctness without ever storing or comparing raw passwords.
This tool exposes that operation in a browser-based UI, making it invaluable for developers who need to debug authentication issues, validate hash storage, or verify output from bcrypt generators during development and testing.
💡 Looking for web development assets? MonsterONE offers unlimited downloads of templates, UI kits, and assets — worth checking out.
How Bcrypt Verification Works
Bcrypt is a password hashing function designed by Niels Provos and David Mazières, first presented at USENIX in 1999. Unlike MD5 or SHA-1, bcrypt is intentionally slow — it uses a cost factor (also called work factor or rounds) that determines how computationally expensive hashing is. This makes brute-force attacks significantly harder as hardware improves.
When a password is hashed with bcrypt, the resulting hash encodes three pieces of information: the algorithm version, the cost factor, and a 128-bit salt concatenated with the 184-bit hash output. A typical bcrypt hash looks like this:
$2b$12$LQv3c1yqBWVHxkd0LHAkCOYz6TtxMQJqhN8/LewdBP5M1FpvHJZde
Breaking this down: $2b$ is the algorithm version, 12 is the cost factor (2^12 = 4,096 iterations), followed by the 22-character salt and the 31-character hash. The salt is automatically embedded in the hash string, which is why password_verify() only needs the hash — it extracts the salt internally.
Understanding the Cost Factor
The cost factor is the most important tuning parameter in bcrypt. It is an exponent: a cost of 12 means 2^12 = 4,096 iterations of the key setup algorithm. Each increment doubles the computation time. At cost 10 (PHP default), a modern server might hash a password in ~100ms. At cost 14, that becomes ~1.6 seconds. At cost 16, ~6.4 seconds.
OWASP recommends a minimum cost factor of 10 for bcrypt, and suggests increasing it periodically as hardware improves. The current recommendation for new applications is 12. Higher cost makes each verification slower for attackers attempting brute force, while remaining barely perceptible to legitimate users on a login screen.
Use this verifier to inspect the cost factor of hashes from your database — if you see $2b$10$, consider migrating to $2b$12$ or higher the next time users authenticate (re-hash on successful login).
Common Verification Failures and How to Debug Them
If this tool reports a mismatch and you expected a match, here are the most common causes:
- Trailing whitespace: A single trailing space in the password or hash will cause a mismatch. Always
trim() user input before hashing or verifying.
- Escaped dollar signs: Some database drivers or config files escape
$ characters. Ensure your hash is read as a raw string without any escaping.
- Encoding issues: If the hash was stored in a column with an incorrect character set, some bytes may have been corrupted. Verify the column is
VARCHAR(255) CHARACTER SET utf8mb4 or similar.
- Truncated hash: A valid bcrypt hash is always 60 characters. If your database column is shorter (e.g.
VARCHAR(45)), the hash may be silently truncated on insert.
- Wrong hash type: MD5, SHA-256, and Argon2 hashes will not verify with
password_verify(). Confirm your stored value starts with $2a$, $2b$, or $2y$.
Bcrypt vs Other Password Hashing Algorithms
Bcrypt remains a solid choice for password storage, but it is worth understanding how it compares to alternatives:
- Argon2: The winner of the Password Hashing Competition (2015). More memory-hard than bcrypt, making GPU attacks harder. PHP supports it via
PASSWORD_ARGON2ID (recommended for new applications on PHP 7.3+).
- scrypt: Like Argon2, tunable for memory hardness. Less widely adopted in PHP ecosystems.
- PBKDF2: Used by many standards (FIPS, NIST) but generally considered weaker than bcrypt for password storage due to GPU parallelism.
- MD5/SHA-1: Never use these for passwords. They are fast hashing algorithms, meaning an attacker with a GPU can test billions of passwords per second.
For PHP applications started before PHP 7.3 or legacy codebases, bcrypt is the appropriate choice. For greenfield projects, consider PASSWORD_ARGON2ID.
Using password_verify() in PHP
In PHP, verifying a bcrypt hash is a one-liner:
if (password_verify($userInputPassword, $storedHash)) {
// Login success
// Optionally re-hash if cost factor is outdated:
if (password_needs_rehash($storedHash, PASSWORD_BCRYPT, ['cost' => 12])) {
$newHash = password_hash($userInputPassword, PASSWORD_BCRYPT, ['cost' => 12]);
// Update stored hash in database
}
} else {
// Login failure
}
The password_needs_rehash() function is particularly useful for transparently upgrading the cost factor of existing user hashes over time — each time a user logs in successfully, you check if their hash needs an upgrade and silently re-hash it before continuing.
Security Best Practices for bcrypt
When implementing bcrypt in your application, follow these guidelines to ensure robust password security:
- Always use PHP's
password_hash() — never implement bcrypt manually.
- Store the full 60-character hash in a
VARCHAR(255) column to future-proof against longer hashes.
- Never log plaintext passwords, even temporarily.
- Rate-limit login attempts to slow down online brute-force attacks, regardless of hashing strength.
- Use constant-time comparison —
password_verify() handles this internally.
- Periodically audit your cost factor and re-hash on login if it is below current recommendations.
- Consider adding a pepper (application-level secret key) as an additional defense layer for offline attacks.