The bcrypt password hashing algorithm silently truncates inputs after the first 72 bytes, causing any characters beyond that limit to be ignored during both hashing and verification. This behavior has existed since the algorithm's introduction in 1999 and remains unchanged to preserve hash compatibility.
Developers discovered the issue when importing accounts from legacy systems. Passwords longer than 72 bytes verified successfully even when they differed in the ignored tail, leading to unexpected authentication results. Tests in PHP using PASSWORD_BCRYPT confirmed that a 72-character string and a 100-character string of the same prefix produce matching verification outcomes.
The root cause lies in Blowfish's P-table, which holds exactly 18 subkeys of 4 bytes each. The original specification fixed this 72-byte boundary, and any excess data is never fed into the key expansion function. Multibyte characters exacerbate the problem: 36 Cyrillic characters reach the limit, while 37 or more are truncated.
Practical risks appear in password managers that store full-length strings, during database migrations between libraries with differing truncation rules, and in corporate environments using long static prefixes. Python's bcrypt package version 4.x now raises an explicit error for inputs over 72 bytes, forcing developers to handle truncation manually or upgrade validation logic.
Mitigations include adding consistent 72-byte length checks on registration and login forms, pre-hashing passwords with SHA-256 encoded in base64 before passing to bcrypt, or migrating to algorithms without length limits such as Argon2id or scrypt. Systems should also audit all code paths that call the hashing function to ensure uniform enforcement.
