Secure Password Best Practices for End Users and Developers

The Modern Standard: NIST SP 800-63B

The authoritative reference for password security in 2025 is NIST Special Publication 800-63B ("Digital Identity Guidelines: Authentication and Lifecycle Management"), Revision 3, published in June 2017 and updated since. The document overturned much of the 2000s-era advice that most users still remember. Mandatory complexity rules ("must contain at least one uppercase, one lowercase, one digit, and one symbol") are out. Mandatory periodic password changes are out. Length is in. Screening against known breached passwords is in.

The shift was driven by data. When NIST examined real-world password breaches — the RockYou leak of 2009, the LinkedIn leak of 2012, the Adobe leak of 2013 — they found that complexity rules produced passwords that were hard for humans to remember but easy for computers to guess, because users responded to the rules in predictable ways: capitalizing the first letter, appending a digit, swapping e for 3 and a for @. The rules did not add entropy; they added predictability.

Length Beats Complexity

Entropy in a password is roughly log2(charset_size) × length bits. A random 8-character password drawn from 94 printable ASCII characters has about 52 bits of entropy, which is borderline against modern GPU brute force — a single RTX 4090 can try roughly 50 billion SHA-256 hashes per second, exhausting 52 bits in under a day. The same 52 bits at 12 characters means the character set can shrink to 64 (still printable ASCII but without the rarest symbols), and at 16 characters a 94-character set produces 105 bits of entropy — comfortably beyond any realistic brute force.

The practical recommendation that follows: minimum 8 characters for low-risk systems, 12 or more for anything sensitive, 15 or more for administrators. Encourage passphrases — sequences of four or five random common words like "correct horse battery staple" — because they are easier for humans to remember than random strings of equivalent entropy. Avoid rules that force specific character classes; instead, screen against breached-password lists and reject anything on them.

Worked Example: Entropy Comparison

"Summer2024!" has 11 characters but only about 28 bits of effective entropy, because it follows a predictable pattern (capitalized season, year, exclamation). A breach database containing the top million patterns will guess it on the first attempt. The 16-character random string "k7\$mP2!qL8vN4#jW" has about 105 bits and would take longer than the age of the universe to brute force at 50 billion hashes per second. The difference is not the length; it is whether the password was chosen to defeat guessing or to satisfy a rule.

Screen Against Breached Passwords

NIST 800-63B explicitly requires verifiers to check newly chosen passwords against a database of known compromised passwords and reject any found there. The standard reference is the Have I Been Pwned password corpus, built from publicly leaked password databases and accessible via a privacy-preserving k-anonymity API: the client sends the first five characters of the password's SHA-1 hash, the server returns all hash suffixes beginning with those five characters, and the client checks for a match locally. This means the password itself never leaves the client.

Top-1000 lists of common passwords ("123456", "password", "qwerty") are a useful additional screen but are dominated by patterns the breached-password check will already catch. The breached-password database grows over time, so the check is ongoing: a password that was safe to choose in 2020 may be on a breached list by 2025.

Allow Paste, Allow Length, No Hints

NIST 800-63B explicitly instructs verifiers to allow paste in password fields, to support password managers. Disabling paste was a 2000s-era anti-pattern that forced users into shorter, weaker passwords they could type reliably. Modern guidance is the opposite: encourage password managers, allow paste, and set the maximum length high enough that a generated 100-character passphrase is not truncated. The "security questions" pattern ("What is your mother's maiden name?") is also out — those answers are easily discoverable from public records and effectively become weak second passwords. If you must use security questions, allow users to disable them in favor of a second authentication factor.

Storage: bcrypt, scrypt, or Argon2id

For developers storing passwords, the rule is: never store the plaintext, never store a plain hash, and never use a fast hash like SHA-256 or SHA-512 even with a salt. Use a password hashing function that is deliberately slow and memory-hard. The three acceptable choices in 2025 are:

• bcrypt (1999). Configurable cost factor that doubles the work per increment. The default of 10 is now too low; 12 or 13 is appropriate for 2025 hardware. Limited to 72-byte passwords; longer inputs are silently truncated, so pre-hash with HMAC-SHA-256 if you must support long passphrases.
• scrypt (2009). Requires both CPU and memory, making GPU and ASIC attacks less efficient. Parameters N (CPU/memory cost), r (block size), p (parallelism) need tuning; reasonable 2025 values are N=2^17, r=8, p=1.
• Argon2id (2015, PHC winner). The current recommendation. Hybrid of Argon2i (side-channel resistant) and Argon2d (GPU resistant). Parameters t (iterations), m (memory in KB), p (parallelism) need tuning; OWASP suggests m=19456 (19 MB), t=2, p=1 as a starting point.

Every password gets a fresh random salt — at least 16 bytes, generated by a cryptographically secure random number generator, stored alongside the hash. The salt's purpose is not to be secret; it is to ensure that two users with the same password get different stored hashes, defeating precomputed rainbow tables and making batch attacks on a stolen database proceed one password at a time rather than all at once.

Rate Limiting and Lockout

Online brute force — repeated login attempts against a live service — is defeated by rate limiting, not by password strength alone. NIST recommends throttling or locking accounts after a small number of failed attempts (commonly 5 to 10), but with two refinements. First, do not reveal whether the username exists; return the same "invalid username or password" message whether the username is unknown or the password is wrong. Second, prefer progressive delays or CAPTCHA over hard lockouts, because hard lockouts become a denial-of-service attack vector: an attacker who knows a username can lock the legitimate user out by deliberately failing logins.

Multi-Factor Authentication

A password alone, however strong, is a single factor. NIST SP 800-63B defines three authentication factors: something you know (password), something you have (a device or token), and something you are (biometric). Multi-factor authentication combines at least two. TOTP codes (RFC 6238) like Google Authenticator and 1Password's built-in TOTP are cheap to deploy and significantly raise the bar. WebAuthn (FIDO2) hardware keys like YubiKey raise it further and resist phishing entirely, because the key cryptographically binds to the origin it is registering with. SMS-based second factors are the weakest option and NIST has deprecated them for new deployments, because SMS can be intercepted via SIM-swap attacks.

Conclusion

Modern password security is built on three NIST 800-63B principles: length over complexity, screening against breached passwords, and the use of slow memory-hard hash functions for storage. End users should use a password manager to generate long random passwords and a unique password for every site; reuse is the single most common cause of cascading breaches. Developers should choose Argon2id or bcrypt, never store plaintext or fast hashes, salt every password, allow paste, and require multi-factor for any account with elevated privileges. The 2000s-era complexity rules were wrong, the periodic-change mandates were wrong, and the security-question pattern was wrong — the modern guidance is simpler, easier on users, and more secure. Written by the HT99 Tools Editorial Team.