Encoding and security guides
bcrypt limits: count UTF-8 bytes before hashing
Test the 72-byte boundary with Unicode passwords and avoid silent truncation in legacy implementations.
Count bytes, not displayed characters
Many bcrypt implementations consider only the first 72 input bytes. Unicode characters can require several UTF-8 bytes each.
A character counter therefore cannot enforce this boundary reliably. Check the exact encoding used by the password library.
new TextEncoder().encode('中'.repeat(24)).length → 72
new TextEncoder().encode('中'.repeat(25)).length → 75Reject instead of silently truncating
Nav Tools rejects passwords above 72 UTF-8 bytes before hashing or comparison. This makes the boundary visible during testing.
In a legacy service that truncates, two passwords sharing the same first 72 bytes may compare identically. Verify the deployed implementation.
Do not invent a prehash migration
Prehashing changes the stored-password scheme and its security assumptions. A naive workaround is not compatible with existing bcrypt records.
Use a reviewed password-storage design and an explicit migration strategy. Keep any algorithm marker with the stored record.
Test cost and compatibility separately
The cost parameter affects computation, not the input byte limit. A higher cost cannot repair truncated-password ambiguity.
The site limits interactive costs to 8, 10 and 12 choices. Select production parameters through measured server performance and current password-storage guidance.