bcrypt is a password hashing algorithm designed to be slow and computationally expensive. It uses a per-password salt and a configurable cost factor to increase the work required for each guess. That makes it more resistant to brute force attacks than fast general purpose hash functions.
How bcrypt Works
bcrypt is a password hashing scheme, not a general-purpose hash. Its slow, tunable work factor forces each guess to take meaningful computation, which is exactly what makes it useful for protecting stored passwords. The per-password salt also ensures that identical passwords do not produce identical hashes, reducing the value of precomputed attacks and password reuse analysis.
Unlike fast hashes used for integrity or fingerprinting, bcrypt is designed so that verification is intentionally expensive. That design choice matters because password storage is a guessing game, and the defender wants each guess to cost far more than the attacker can efficiently automate at scale.
Why bcrypt Is Used for Password Storage
bcrypt fits the narrow but important problem of storing secrets that users can memorise and re-enter. It is especially relevant when an application must compare a submitted password against a stored verifier without ever storing the password itself in recoverable form. The salt protects against shared-hash reuse, while the cost factor lets defenders increase resistance as hardware improves.
For practitioners, bcrypt is part of the broader password storage decision: what algorithm to use, how to set its cost, how to migrate legacy password databases, and how to avoid weakening the scheme by treating it like a generic hash. A bcrypt hash should be handled as password-verifier material, not as a simple checksum.
bcrypt Limitations and Trade-offs
bcrypt is stronger than fast hashes for password protection, but it is not a magic shield. Any password hashing scheme still depends on password strength, breach hygiene, and sensible operational controls. If users choose weak or reused passwords, bcrypt only slows the attacker down; it does not change the underlying guessability of the secret.
bcrypt also carries implementation trade-offs. Its cost factor must be tuned to the environment, and the chosen setting should reflect the acceptable verification latency for real users and systems. Over time, teams may also need to consider migration to newer password hashing schemes when platform, policy, or performance requirements change.
bcrypt in a Secure Authentication Stack
bcrypt protects one part of the authentication lifecycle: password verification at rest. It does not replace multi-factor authentication, session protections, credential stuffing defences, account lockout logic, or identity recovery controls. In practice, bcrypt is most effective when it sits inside a broader authentication design that also limits online guessing and reduces the blast radius of compromised passwords.
That wider view matters because password hashing is only one control point. A strong verifier does little if passwords are exposed elsewhere, if admin accounts share weak credentials, or if session tokens are mishandled after login.
Risk and Threat Considerations
Weak password hashing creates direct exposure to offline cracking after a database theft, because attackers can test guesses at scale until they recover usable passwords. bcrypt reduces that risk by making each guess slower and by preventing identical passwords from producing identical stored hashes, but weak passwords, low work factors, or poor migration practices can still leave accounts exposed.
Failure mechanism: An attacker who obtains the password database can brute-force or credential-stuff against weakly protected verifiers, then reuse recovered passwords elsewhere.
Impact: Successful cracking can lead to account takeover, privilege abuse, lateral movement, and exposure of any systems protected by the compromised credentials.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | bcrypt protects stored password authenticators and their lifecycle. |
| IA-2 — Identification and Authentication (Organizational Users) | bcrypt is part of user authentication for organisational accounts. | |
| IA-8 — Identification and Authentication (Non-Organizational Users) | bcrypt also protects external user passwords stored by services. | |
| Recommendation — Use IA-5 to manage password verifiers, rotation, and related authenticator handling. Apply IA-2 to authenticate users before granting access to protected resources. Apply IA-8 to authenticate external users with properly protected password verifiers. | ||
| OWASP ASVS | V6 — Authentication | bcrypt is a password hashing choice that supports application authentication requirements. |
| V7 — Session Management | bcrypt protects login credentials, which precede session issuance and session security. | |
| Recommendation — Verify that passwords are stored with a modern password hashing scheme and tuned parameters. Pair secure password hashing with strong session controls after successful authentication. | ||
Practitioner Guidance
Why practitioners should care: bcrypt is not just a library choice, it is a password storage control decision. The right implementation preserves resistance to offline guessing while giving the organisation room to raise the work factor over time. The wrong implementation can quietly weaken authentication even when the algorithm name looks familiar.
What to watch for: Treat bcrypt as one layer in the password lifecycle, not as a substitute for password policy, MFA, breach monitoring, or secure session handling. If migration from older hashes is underway, ensure the application can verify legacy passwords once and then rehash them under the current scheme.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org