Last updated:
Password Length and Security - Choosing the Right Length
Password length is the single most important factor in password security. Each additional character multiplies the number of possible combinations by roughly 95×, making brute-force attacks exponentially harder. This guide goes beyond surface-level advice to cover entropy calculations, hash function costs, the order of magnitude of time a brute-force search requires, passphrase vs. random string trade-offs, and multi-factor authentication strategies - all grounded in NIST SP 800-63B, whose fourth edition was published in 2025.
Entropy and Password Strength
Entropy, measured in bits, quantifies how difficult a password is to guess. The formula is straightforward:
Entropy (bits) = log2(charset sizelength) = length × log2(charset size)
With the full printable ASCII set of 95 characters, each character contributes approximately 6.57 bits of entropy. An 8-character password yields about 52.6 bits, 12 characters about 78.8 bits, and 16 characters about 105.1 bits. There is no absolute threshold at which a given number of bits becomes "safe." Entropy only acquires meaning when multiplied out against an assumed attack rate: the same 52.6 bits falls in hours against a fast hash computed at billions of attempts per second, yet stands for years against a deliberately slow one. Rather than aiming at a fixed bit count, aim to stay several orders of magnitude ahead of whatever rate an attacker could plausibly sustain, which in practice means adding length.
A critical insight: increasing length is more effective than increasing character variety. A 16-character lowercase-only password (26 chars) has about 75.2 bits of entropy - nearly matching a 12-character password using all 95 characters (78.8 bits). Extend that lowercase password to 20 characters and entropy reaches about 94 bits, surpassing a 14-character full-charset password (about 92 bits). This is the mathematical basis for why length matters more than complexity.
NIST SP 800-63B Guidelines
NIST's SP 800-63B is the international benchmark for password policy. Its fourth edition was published in August 2025 and supersedes the earlier revision, so any summary written against the older text is out of date. The fourth edition places length at the center of the requirements and removes the character-composition rules that older policies leaned on.
- A password used on its own must be at least 15 characters (stated as a SHALL requirement)
- A password used as one factor alongside another authenticator must be at least 8 characters (also a SHALL)
- Verifiers should accept passwords of at least 64 characters, so that long passphrases are never rejected
- Composition rules (requiring a mix of uppercase, digits, and symbols) must not be imposed. The reasoning is behavioral: faced with such a rule, people apply the smallest possible edit, such as capitalizing the first letter or appending "1!", and a predictable edit barely widens the search space an attacker has to cover
- Changes must not be forced on a schedule. Passwords may only be required to change when there is evidence the credential has been compromised
- New passwords must be screened against a blocklist of known-compromised and commonly used values, and the comparison applies to the password as a whole rather than to fragments of it
- No minimum entropy value is required. The guidelines set requirements on length, screening, and handling, and deliberately avoid prescribing a bit threshold
How Long a Brute-Force Search Takes
The figures below are a worked example, not a measurement of any particular device. They assume an attacker who can test 1011 candidates per second against a password drawn from the full 95-character printable ASCII set, and they show the time needed to exhaust that space.
| Length | Combinations | Entropy | Est. time (assuming 1011 attempts/sec) |
|---|---|---|---|
| 6 chars | ~735 billion | ~39.4 bits | ~7 seconds |
| 8 chars | ~6.6 quadrillion (6.63 × 1015) | ~52.6 bits | ~18 hours |
| 10 chars | ~6 × 1019 | ~65.7 bits | ~19 years |
| 12 chars | ~5.4 × 1023 | ~78.8 bits | ~1.7 × 105 years |
| 16 chars | ~4.4 × 1031 | ~105.1 bits | ~1.4 × 1013 years |
This table only holds when a single hash computation is very cheap. If the storage side uses a deliberately expensive hash such as bcrypt or Argon2id, the number of candidates testable per second drops by several orders of magnitude on the same hardware and every figure in the table stretches accordingly. Conversely, if passwords are stored with a fast hash like MD5, short ones fall within a practical amount of time. The same 8 characters can therefore be strong or weak depending entirely on the server-side implementation. Since users cannot choose that implementation, the best defense available on the user side is simply to set a sufficiently long password.
Hash Function Costs and Password Length
Password security depends not only on length but also on the computational cost of the server-side hash function. Here is a comparison of major algorithms:
| Algorithm | Role in password storage |
|---|---|
| MD5 | A single computation is extremely cheap and can be run massively in parallel on a GPU. Unsuitable for storing passwords, yet it persists in legacy systems |
| SHA-256 | Heavier than MD5, but still designed to be computed quickly. Remains inadequate for password storage |
| bcrypt | Deliberately slowed by design. The cost factor lets the work be tuned upward as hardware gets faster. Truncates its input to 72 bytes |
| Argon2id | Selected in the 2015 Password Hashing Competition. Its memory-hard design demands memory as well as computation time, which resists parallel GPU attacks. RFC 9106 recommends it as the first choice |
| scrypt | Memory-hard design. The recommended algorithm before Argon2 arrived |
bcrypt truncates input to 72 bytes, meaning ASCII-only passwords are effectively capped at 72 characters, and UTF-8 Japanese text at roughly 24 characters. This limitation directly influences maximum password length on some platforms. Argon2id has no such restriction and can process passwords of arbitrary length. New services should prefer Argon2id.
Even with slow hashes like bcrypt or Argon2id, short passwords remain vulnerable to dictionary and rule-based attacks. Hash cost is a delaying tactic; the fundamental defense is sufficient length (entropy).
Why Length Matters More Than Complexity
Many services require "at least one uppercase letter, one number, and one symbol," but NIST explicitly rejects this approach. The numbers tell the story clearly.
"P@ssw0rd!" is 9 characters using all four character types, yet it sits near the top of breached-password lists. Attackers try substitutions like a to @ and o to 0 against "password" from the very start, so meeting the character-type requirement has barely widened the space that has to be searched. Compare "mountain river cloud forest", four lowercase words joined by spaces for a total of 27 characters. Even if an attacker works out the structure and searches only arrangements of four words drawn from a 7,776-word list, that space is equivalent to about 51.7 bits, and raising it to six words reaches about 77.5 bits. What separates the two is not how many character types are present but how wide the range of choices is.
Complexity rules backfire for three reasons. First, users satisfy requirements with predictable patterns (capitalize the first letter, append "1!"). Second, complex passwords are hard to remember, so users keep them short. Third, unmemorable passwords end up stored in plaintext on sticky notes or text files.
Passphrases vs. Random Strings
Two approaches exist for creating long passwords: passphrases and random character strings. Each has distinct trade-offs.
| Aspect | Passphrase | Random String |
|---|---|---|
| Example | correct horse battery staple | kX9#mP2$vL7@nQ4 |
| Length | 28 characters | 15 characters |
| Entropy | ~51.7 bits (4 words from a 7,776-word list) | ~98.5 bits (95 chars × 15) |
| Memorability | High (story-based recall) | Low (password manager required) |
| Typing ease | High (normal typing) | Low (special characters are cumbersome) |
| Dictionary attack resistance | Depends on word count and list size | Extremely high |
The trap to avoid here is judging a passphrase by its character count, which overstates its strength by a wide margin. The example above runs to 28 characters, but an attacker who assumes the structure of four words picked from a word list has only four words' worth of combinations to try. Passphrase strength is set by the number of words and the size of the word list. With the Diceware approach and its 7,776-word list, four words give about 51.7 bits and six words about 77.5 bits. Using only common everyday words weakens the passphrase against dictionary attacks, so combining unrelated words randomly is essential. "My cat is cute" is a poor passphrase; "chair purple submarine cayenne galaxy" is far stronger.
Use passphrases for master passwords (unlocking your password manager) and random strings generated by the password manager for individual service accounts.
Dealing With Service-Side Length Limits
Minimum and maximum lengths differ from service to service, and few services document their upper limit publicly. Google's help pages, for instance, state a recommendation of 12 characters or more but say nothing about a maximum. Values like these also change without notice, so rather than trusting a third-party roundup, it is more reliable to find out what length your own account actually accepts. Generate a 32-character password in your password manager, and if it is rejected, step down to 24 and then 16 until you have located the effective ceiling.
One technical reason limits exist is the bcrypt 72-byte boundary described earlier: showing a limit at the input stage makes the behavior clearer than silently truncating during hashing. Another is design left over from an era when passwords were stored in short fixed-length columns, which can leave a ceiling of only a few dozen characters. Either way the response is the same. Set the longest password the service permits, and where the ceiling is low, always pair it with multi-factor authentication.
You will also meet services whose minimum is as loose as six characters. The floor a service allows is not a statement about what length is safe. Whatever the operator requires, the length you choose is still yours to decide.
Multi-Factor Authentication Synergy
No matter how long a password is, it becomes useless if stolen via phishing or keyloggers. Password length defends against brute-force attacks, while multi-factor authentication (MFA) defends against credential theft - different attack vectors that complement each other powerfully.
- TOTP (Time-based One-Time Password): Apps like Google Authenticator or Authy generate 6-digit codes that refresh every 30 seconds. Stolen codes expire quickly, but real-time phishing proxies can relay them before expiration
- FIDO2 / WebAuthn (Passkeys): Physical security keys or device biometrics offer the strongest phishing resistance, because the credential is bound to the identity of the site it was registered for and the authenticator verifies that it is talking to that same site before signing. A lookalike domain therefore cannot obtain a usable response, even from a user who is fooled. SP 800-63B in its fourth edition treats this class of authenticator as phishing resistant, and Apple, Google, and Microsoft are all promoting "passkeys" as the successor to passwords
- SMS authentication: Convenient but vulnerable to SIM-swap attacks and SS7 protocol interception. The fourth edition designates out-of-band authentication carried over the public telephone network as RESTRICTED, so migrating to TOTP or FIDO2 is advisable wherever possible
The ideal setup is a long password (or passphrase) combined with a FIDO2 security key. This provides strong resistance against brute-force attacks, dictionary attacks, phishing, and credential stuffing simultaneously.
Password Manager Best Practices
- Master password: Use a Diceware passphrase of 6+ words (77+ bits of entropy). Never store the master password anywhere - commit it to memory only
- Generated password length: Set individual service passwords to 20+ random characters. Considering bcrypt's 72-byte limit, 20–64 ASCII characters is the practical sweet spot
- Clipboard auto-clear: Enable automatic clipboard clearing after 10–30 seconds to prevent copied passwords from lingering
- Browser built-in vs. dedicated managers: Chrome and Safari's built-in password managers offer solid encryption, but dedicated tools provide cross-platform support, security audits, and shared vaults for teams
Breach Checking and Password Policy Design
Practical guidelines for both individual users and service developers:
For individual users:
- Regularly check haveibeenpwned.com to see if your email appears in known breaches. The site's API uses a k-anonymity model that sends only the first 5 characters of your password hash - your actual password is never transmitted
- Use your password manager's security audit feature to detect weak passwords, reused credentials, and breached passwords in one sweep
- Prioritize high-value accounts (email, financial, social media). Email accounts deserve the strongest protection since they serve as password reset channels for other services
For service developers:
- Require at least 15 characters where the password stands alone as the sole authenticator, and at least 8 where it is combined with another factor. These are the two tiers set out in SP 800-63B
- Allow at least 64 characters maximum. Unnecessarily short limits restrict user security
- Skip character-type requirements. Instead, implement breached password screening using APIs like Have I Been Pwned
- Choose Argon2id as the primary hash algorithm, with bcrypt (cost factor 12+) as fallback. Never use plain MD5 or SHA-256 for password storage
- Provide real-time feedback with a strength meter that estimates how many guesses a password would take, taking dictionaries, known patterns, and keyboard layouts into account. Libraries such as zxcvbn work this way. A meter that merely scores how many character types are present will happily rate "P@ssw0rd!" highly, which is the opposite of useful
Common Mistakes and Countermeasures
- Using dictionary words as-is: Words like "sunshine," "football," and "dragon" fall to dictionary attacks instantly. Attackers use multi-million-word dictionaries plus l33t speak transformations (a→@, e→3) and keyboard patterns (qwerty, 1qaz2wsx)
- Including personal information: Birthdays, pet names, and partial addresses are easily guessed from social media profiles and data breaches. Attackers routinely build custom dictionaries from targets' public information (social engineering)
- Reusing passwords across services: One breach exposes every account sharing that password. This attack, known as credential stuffing, replays leaked username and password pairs automatically against other services, and no amount of length prevents it because the password is already known. A single match is enough to get in, so the only real countermeasure is a different password for every service, which is precisely why a password manager is necessary
- Making minimal variations: "MyPassword1," "MyPassword2," "MyPassword3" - rule-based attacks easily generate these variants from a single leaked version. Tools for this are widely available
Conclusion
Password security depends on entropy, and the most efficient way to increase entropy is to add length. NIST SP 800-63B requires at least 15 characters for a password used on its own and at least 8 when it is one of several factors, and pairing long passwords with slow hashes like bcrypt or Argon2id provides effective real-world protection. Individual users should generate 20+ character random passwords via a password manager, using a Diceware passphrase as the master password. Adding FIDO2/passkey-based multi-factor authentication achieves the highest level of defense currently available. Check your password length with Character Counter.