bcrypt truncates passwords at 72 bytes, so longer inputs can be silently reduced to the first 72 bytes. That creates unexpected collisions, weakens user intent, and can become dangerous if developers try to pre-hash around the limit without handling encoding carefully.
How bcrypt’s 72-byte limit changes password handling
bcrypt does not process an arbitrarily long password as a single unique input. Once an input exceeds 72 bytes, the extra bytes are ignored, so two different passwords can collapse to the same bcrypt input. The practical break is not just “long passwords fail”, but that the system may quietly accept more than the user actually proved.
That matters most when user interfaces, password managers, or paste-friendly workflows allow long passphrases. If the application does not enforce a safe input boundary, the user can believe every character counts while the verifier only sees the prefix.
Where collisions and intent mismatch show up
When the 73rd byte and beyond are discarded, distinct secrets can become equivalent under verification. That creates collision risk, but the more subtle failure is intent mismatch: a user may rotate to a new long password and assume the whole phrase now matters, while an attacker who knows only the first 72 bytes can still authenticate.
Encoding makes this easier to get wrong. A password’s character count is not the same as its byte count, so multibyte characters can hit the limit earlier than expected. If your application counts characters but bcrypt enforces bytes, the effective cutoff will not match what the user sees.
Why pre-hashing is a dangerous workaround if you do it casually
Some teams try to sidestep the limit by pre-hashing the password before bcrypt. That can work only if the transformation is deliberate, fixed, and consistently applied, because otherwise you risk changing the authentication contract without telling users or breaking migration paths. A careless pre-hash can also reduce the benefits of long user-chosen passphrases if the encoding or normalization steps are inconsistent.
For this reason, the safe design question is not “Can we make bcrypt accept more?” but “Can we preserve the full user secret without introducing ambiguity?” If the answer is no, the control needs to move to a password hashing scheme and input policy that handles the full length cleanly.
Risk and Threat Considerations
Unbounded bcrypt input creates a quiet security failure, not an obvious validation error. The risk is strongest when application code, identity workflows, or password managers encourage long passphrases, because the user interface may suggest stronger protection than the hash verifier actually provides.
Failure mechanism: bcrypt truncation at 72 bytes causes silent equivalence between different long inputs, and byte-level handling can diverge from character-based validation or normalization.
Impact: Users can be locked into weaker-than-intended authentication, collision-based account access becomes possible at the prefix level, and migration or pre-hash workarounds can introduce fresh implementation bugs.
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, OWASP ASVS and CIS Controls v8 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 truncation affects password authenticator handling and lifecycle. |
| IA-7 — Cryptographic Module Authentication | Password hashing is part of authentication strength and verifier design. | |
| Recommendation — Set password length policy and hashing rules so authenticators are handled consistently. Use approved authentication mechanisms that preserve the full secret input. | ||
| OWASP ASVS | V6 — Authentication | Password length handling and hashing behaviour are core authentication requirements. |
| V14 — Data Protection | Password storage and transformation must protect the secret without silent weakening. | |
| Recommendation — Verify password processing limits and hashing behavior under authentication tests. Protect password material with a hashing design that avoids truncation surprises. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account authentication depends on predictable, safe credential handling. |
| Recommendation — Review account authentication flows for input limits and credential-processing defects. | ||
Practitioner Guidance
What to verify: Confirm whether your login path measures password length in bytes, characters, or normalized bytes, and test with multibyte passphrases rather than ASCII-only examples. Verify that the behaviour is consistent across web, mobile, API, and password reset flows.
Decision rule: If you cannot guarantee that the verifier and the UI apply the same length semantics, enforce a safe maximum at input time and document it clearly; do not rely on users to discover the limit through failed authentication.
Common mistake: Treating pre-hashing as a drop-in fix. If you introduce it, preserve the exact encoding and normalization rules everywhere, or you may create a different class of silent mismatch.
Practitioner takeaway: The real control objective is consistency, the user must know what is being authenticated, and the verifier must never ignore part of that secret without an explicit design decision.