Bcrypt's 72-Byte Limit — Why Korean Passwords Get Cut at 24 Characters
When hashing passwords with bcrypt, you'll commonly see it described as supporting "up to 72 characters" — but the limit is actually 72 bytes, which is a completely different thing from "72 characters." In English, this distinction barely shows up in practice. But the moment you use a Korean password, that difference turns into a real security problem. This guide explains why bcrypt is capped at exactly 72 bytes, why Korean is especially vulnerable to this issue, and how to work around it in practice — starting from the underlying calculation.
1. Why is bcrypt limited to 72 bytes?
bcrypt is a password-hashing algorithm designed in 1999 by Niels Provos and David Mazières. Internally, it works by repeatedly transforming the key schedule of the Blowfish cipher to drive up computational cost. Blowfish's key schedule function was originally designed to accept an input key of at most 448 bits, i.e. 56 bytes, and when bcrypt extended this, the way it handles the salt fixed the practical limit at 72 bytes of UTF-8-encoded password bytes actually used in the hashing computation. This isn't a bug or an implementation mistake in any particular library — it's a fundamental limitation of the algorithm specification itself, and anything past 72 bytes is silently ignored, without any error or notice that truncation happened. In other words, from the 73rd byte onward, no matter what you change, it has zero effect on the resulting hash.
2. Why Korean is especially vulnerable — the UTF-8 encoding structure
The 72-byte limit itself applies equally to every password, but how many "characters" actually get reflected in the hash varies enormously depending on the encoding. In UTF-8, English letters, digits, and some symbols each take up 1 byte per character, so the 72-byte limit is practically almost the same as a 72-character limit. Korean syllable characters (가~힣), on the other hand, take up 3 bytes per character in UTF-8. So dividing 72 bytes by 3 bytes gives 72 ÷ 3 = 24 characters as the actual limit reflected in the hash — anything from the 25th character onward is ignored entirely, no matter how long the input is.
| Character type | UTF-8 bytes/character | Characters representable in 72 bytes |
|---|---|---|
| English/digits (ASCII) | 1 byte | 72 characters |
| Korean syllables | 3 bytes | 24 characters |
For example, take two passwords that share the same first 24 Korean characters — say "가나다라마바사아자차카타파하규모두의툴생성XXXX" (24 characters + 4 more) — and only differ in the last 4 characters, one ending in "XXXX" and the other in "YYYY." Since the first 72 bytes are completely identical, the resulting bcrypt hashes are identical too. A user who types a Korean password longer than 24 characters, without realizing it, ends up with the effective strength of a 24-character password.
3. How modoohub.com's bcrypt-generator.html handles this
Rather than silently truncating input, this site's bcrypt generator handles the problem with a real-time warning. Every time you type into the password field, it calculates the UTF-8 byte length using TextEncoder, and the moment it exceeds 72 bytes, it immediately displays a warning: "⚠️ Currently N bytes — bcrypt ignores anything past 72 bytes." The actual hashing itself is delegated entirely to the bcryptjs library (running in-browser, served via cdn.jsdelivr.net), and the input is never pre-truncated or substituted — in other words, it's a "warn only, don't truncate" design. The intent is for the user to notice the problem and either adjust their password themselves, or apply the pre-hashing workaround described below.
4. How to work around the 72-byte limit in practice
If you're implementing a server-side authentication system yourself, the most common workaround is to not feed the original password into bcrypt directly, but to first hash it with SHA-256 and use that result (always a fixed 32-byte length) as bcrypt's input. Since SHA-256 always produces a 256-bit (32-byte) output regardless of input length, no matter how many Korean characters or how many thousands of English characters the original password has, the number of bytes going into bcrypt stays fixed at 32 bytes — comfortably within the 72-byte limit. When using this approach, though, you need to be consistent across the entire project about whether you feed in the SHA-256 output as a base64 or hex string, or as raw bytes — and if you already have hashes stored where the original password was fed straight into bcrypt, switching to this approach requires a full rehash (a migration that happens on the user's next login). Switching entirely to a modern algorithm without the 72-byte limit, such as Argon2, is also a viable fundamental alternative.
5. Summary — the order of checks to run
- Check your password's byte count: first verify you're not exceeding 24 Korean characters or 72 English characters.
- Audit your existing system: if your server feeds the original password straight into bcrypt, check whether anything past 72 bytes is being silently ignored.
- Consider adopting pre-hashing: if you have long passwords or many multilingual users, consider SHA-256 pre-hashing or switching to Argon2.
Frequently Asked Questions
Q. Why does bcrypt only use the first 72 bytes for hashing?
A. bcrypt's internal algorithm, a modified Blowfish key schedule, was fixed from its original design to accept an input key of at most 72 bytes. This isn't a bug in any particular library — it's a limitation of the bcrypt algorithm specification itself. Anything past 72 bytes is silently truncated and never factored into the hash calculation at all, with no error or warning.
Q. Why do Korean passwords get cut off so much shorter than English ones?
A. English letters and digits each take up 1 byte per character in UTF-8, so they use nearly all 72 characters. Korean characters, however, take up 3 bytes per character in UTF-8, so once you divide 72 bytes by 3 bytes you get 24 characters — anything past the 24th character is ignored entirely.
Q. Do two Korean passwords that differ only after the 24th character really produce the same hash?
A. Yes. If the first 24 characters (72 bytes) are identical and the two passwords only differ from the 25th character onward, the bytes that actually go into the bcrypt calculation are identical, so the resulting hash is identical too. This was confirmed directly by reproducing it with the bcryptjs library on modoohub.com's bcrypt-generator.html.
Q. How do you work around this 72-byte limit in practice?
A. The most common workaround is to not feed the original password into bcrypt directly, but to first hash it with SHA-256 — which always produces a fixed 32-byte value — and feed that result into bcrypt instead. That way, no matter how long the original password is, the number of bytes going into bcrypt is always fixed at 32, comfortably within the 72-byte limit.