Under the hood · 5 min read

Password length limits: minimums, maximums, truncation

Length limits explained: the NIST minimums, why a maximum of at least 64 is expected, the bcrypt 72-byte edge, and the math of a truncated password.

Length is the single biggest factor in how hard a random password is to guess, so the limits a site puts on length matter. Too low a minimum lets weak passwords through. Too low a maximum stops people using strong ones, and a hidden maximum can quietly throw part of a password away.

What NIST says

NIST SP 800-63B-4, the US federal guideline on authentication, sets out both ends:

• Minimum: “Verifiers and CSPs SHALL require passwords that are used as a single-factor authentication mechanism to be a minimum of 15 characters in length.” When the password is only one part of multi-factor authentication, it may be shorter, but at least eight characters.
• Maximum: “Verifiers and CSPs SHOULD permit a maximum password length of at least 64 characters.”
• No truncation: “Verifiers SHALL request the password to be provided in full (not a subset of it) and SHALL verify the entire submitted password (e.g., not truncate it).”
• Counting: “Each Unicode code point SHALL be counted as a single character when evaluating password length.”

Its Appendix A gives the reasoning for long maximums: “Since the size of a hashed password is independent of its length, there is no reason to prohibit the use of lengthy passwords (or passphrases) if the user wishes.” It also allows a sensible ceiling, because “extremely long passwords (perhaps megabytes long) could require excessive processing time to hash.”

Why a short maximum is a warning sign

A properly stored password is run through a password hashing function, which outputs a fixed-size result whatever the input length (see password hashing explained). A 10-character password and a 60-character one take the same space in the database.

So when a site caps passwords at, say, 12 or 16 characters, the hash is not the reason. Sometimes the cause is harmless: an old form, a legacy system, or a cautious developer. But a short cap can also suggest that the password is stored in a fixed-width field as plain text or reversible encryption, where length really does matter. From the outside there is no way to tell which. A short maximum is a signal worth noting, not proof of anything.

The bcrypt 72-byte limit

One common hashing algorithm has a real input limit. bcrypt, widely used for password storage, only processes the first 72 bytes of its input. The OWASP Password Storage Cheat Sheet says: “bcrypt has a maximum length input length of 72 bytes for most implementations, so you should enforce a maximum password length of 72 bytes (or less if the bcrypt implementation in use has smaller limits).”

Many implementations do not reject longer input. They ignore everything after byte 72. Two passwords that share the first 72 bytes then hash identically.

Bytes are not characters

The limit is in bytes, and in UTF-8 encoding, characters vary in size:

NIST counts characters as code points, bcrypt counts bytes. A 40-character password made entirely of two-byte letters is 80 bytes, within NIST’s 64-character expectation but beyond bcrypt’s reach.

Passphrases and the 72-byte edge

Passphrases are long by design. EFF large-list words are 3 to 9 letters, about 7 on average. With a single-space separator:

Six or seven words always fit in 72 bytes. Eight words can exceed it, and ten usually will. On a system that truncates at 72 bytes, the tail of a long passphrase does nothing. Even then, 72 bytes of a random passphrase still hold several whole words; the problem is that the strength figure shown when it was generated is no longer accurate.

OWASP describes a workaround for developers, pre-hashing the password before bcrypt, and warns that doing it carelessly introduces new weaknesses. Newer algorithms such as Argon2 do not have this limit.

Worked example: what truncation costs

Suppose a 20-character password drawn at random from all 94 printable ASCII characters. It carries 20 × log2(94) = 131.09 bits.

Now suppose the system silently keeps only the first 8 characters. Those 8 characters are just as random as before, but only 8 of them count: 8 × 6.555 = 52.44 bits. The other 78.65 bits are thrown away.

Using the site’s three illustrative attack rates:

The 8-character figure: 94^8 is about 6.1 × 10^15 possibilities; half of that at 10^11 guesses per second is about 30,500 seconds, roughly 8.5 hours. Older Unix systems using the traditional DES-based crypt function behaved exactly this way: only the first eight characters counted.

The person who chose the password has no way to see this happening. They typed 20 characters and the login works, because their first 8 characters are right. That is why NIST makes “verify the entire submitted password” a SHALL.

Minimums in practice

NIST’s 15-character minimum is a length rule, and length is only a proxy for strength. A random 15-character password from all 94 printable characters carries 15 × 6.555 = 98.32 bits. Three random EFF words with spaces usually pass a 15-character rule too (about 23 characters on average), yet carry only 38.77 bits, which the site’s fast-hash illustration puts at about 2.4 seconds on average. Length helps most when the characters, or words, are chosen at random and there are enough of them. See how many words in a passphrase and length beats complexity.

This site’s passphrase generator defaults to 6 words, which always fit within 64 characters with single separators, and the password generator defaults to 20 characters. For how characters beyond ASCII interact with length and hashing, see character sets and look-alikes.

General explanation, not advice for a particular situation. Updated 2026-10-31.