Password Security Best Practices Have Changed
Everything you learned about password security best practices in 2010 is wrong. Mandatory special characters, forced rotation every 90 days, "strength meters" that reward P@ssw0rd! — all of this produces weaker passwords in practice. NIST published updated guidelines (SP 800-63B, revised 2024) that explicitly recommend against complexity rules. Microsoft, Google, and the UK's NCSC followed suit. The research is clear: complexity requirements lead to predictable patterns, while length alone produces better real-world security.
Here's why the old rules failed. When you force users to include uppercase, lowercase, digits, and symbols in an 8-character password, they don't generate random strings. They write "Password1!" or "Summer2024$" or their dog's name with a capital letter and exclamation mark. Attackers know this. Every cracking dictionary includes these patterns. A 2023 analysis of 500 million breached passwords found that 83% of passwords meeting "complex" requirements followed fewer than 20 predictable patterns.
The new consensus: a 16-character lowercase passphrase like "correct horse battery staple" has more entropy than "Tr0ub4dor&3" and is easier to remember. Length is the single most important factor because it exponentially increases the search space. Each additional character multiplies the possibilities by the size of the character set (26 for lowercase, 95 for all printable ASCII).
How Password Entropy Actually Works
Entropy measures the unpredictability of a password in bits. A truly random password drawn from N possible characters with length L has entropy = L × log2(N) bits. An 8-character password using all 95 printable ASCII characters has 8 × 6.57 = 52.6 bits of entropy. A 16-character lowercase-only password has 16 × 4.7 = 75.2 bits. The longer password is astronomically harder to crack despite using a smaller character set.
But here's the catch: entropy calculations assume the password is truly random. "password123456" is 14 characters from a 36-character set, which theoretically gives 72.4 bits of entropy. In practice it has near-zero effective entropy because it's in every cracking dictionary. Entropy only measures strength against brute-force attacks, not dictionary attacks. This is why our password generator tool uses cryptographically secure randomness — human-chosen passwords almost never achieve their theoretical entropy.
How much entropy do you actually need? Against offline attacks (where an attacker has your hashed password and unlimited guesses), you need enough entropy to outlast their hardware. A modern GPU rig can try 100 billion MD5 hashes per second. At that rate: 40 bits of entropy falls in 11 seconds. 50 bits takes 3 hours. 60 bits takes 133 days. 70 bits takes 374 years. 80 bits takes 383,000 years. Aim for 70+ bits for important accounts.
Against online attacks (login forms with rate limiting), even 30 bits of entropy is sufficient if the service locks accounts after 10 failed attempts. The real threat is offline cracking after a database breach. This is why the hashing algorithm matters as much as password strength — bcrypt with cost factor 12 reduces that 100 billion guesses/second to about 5,000 guesses/second per GPU.
What NIST 800-63B Actually Recommends
The NIST Digital Identity Guidelines (SP 800-63B, section 5.1.1) are the gold standard for password security best practices in government and enterprise. Here's what they say, stripped of bureaucratic language: Minimum 8 characters (they recommend allowing up to 64). No composition rules (no forced uppercase/symbols). No periodic rotation unless there's evidence of compromise. Screen passwords against breach databases. Allow paste in password fields.
The "no rotation" recommendation surprises people. NIST's reasoning: forced rotation causes users to make minimal changes (Summer2024 → Fall2024 → Winter2025) that attackers can predict. If a password is strong and not compromised, changing it adds no security. Change passwords only when: you suspect a breach, the service reports unauthorized access, or you're reusing it somewhere that got breached.
Screening against breach databases means checking new passwords against lists like Have I Been Pwned's 900+ million compromised passwords. The k-anonymity API lets you check without sending the full password — you send the first 5 characters of the SHA-1 hash and get back all matching hashes to compare locally. If the password appears in a breach, reject it regardless of its entropy.
One thing NIST doesn't say but I will: use a password manager. The only way to have unique, high-entropy passwords for every service is to not remember them. 1Password, Bitwarden, or KeePass generate and store random passwords. Your one master password (make it a long passphrase) protects everything else. In 2026, this isn't optional — it's the baseline.
How Passwords Get Cracked (Attack Methods)
Brute force: Try every possible combination. Against an 8-character password using all 95 printable ASCII characters (6.6 quadrillion combinations), a single RTX 4090 cracking MD5 hashes at 164 billion/second finishes in 11 hours. Against bcrypt (cost 12), the same GPU manages ~70 hashes/second, making brute force take 3 trillion years. The hashing algorithm is your last line of defense.
Dictionary attacks: Try common passwords, words, names, and known patterns. The RockYou breach (2009, 32 million passwords) showed that "123456" was used by 290,000 accounts. Modern dictionaries include leaked passwords from every major breach, common substitutions (a→@, e→3, o→0), and keyboard patterns (qwerty, zxcvbn). A dictionary attack with rules (append digits, capitalize first letter) cracks 60-70% of human-chosen passwords in minutes.
Credential stuffing: Take email/password pairs from one breach and try them on other services. This works because 65% of people reuse passwords across sites (Google/Harris Poll, 2019). The Zoom credential stuffing attack in 2020 compromised 500,000 accounts using passwords from unrelated breaches. This is why unique passwords per service matter more than password strength.
Rainbow tables: Precomputed hash-to-password lookup tables. A rainbow table for all 8-character alphanumeric passwords (MD5) is about 460 GB. This is why salting exists — adding a random value to each password before hashing makes precomputed tables useless. Any modern hashing algorithm (bcrypt, scrypt, Argon2) includes salting by default. If you're storing passwords with unsalted MD5 or SHA-256, you're doing it wrong.
Password Storage: Hashing Done Right
Never store passwords in plaintext. Never store them encrypted (encryption is reversible — if your server is compromised, the key is too). Always hash them with a purpose-built password hashing function. The correct choices in 2026 are: Argon2id (winner of the Password Hashing Competition, 2015), bcrypt (battle-tested since 1999), or scrypt (memory-hard, good for preventing GPU attacks).
Why not SHA-256? Because SHA-256 is designed to be fast. A GPU can compute 10 billion SHA-256 hashes per second. Password hashing functions are deliberately slow — bcrypt with cost factor 12 takes about 250ms per hash on a modern CPU. This slowness is the point. It makes brute-force attacks computationally expensive for attackers while being imperceptible to legitimate users (you only hash once per login).
Argon2id parameters for 2026: minimum 64 MB memory, 3 iterations, 4 parallelism threads. These parameters force attackers to use 64 MB of RAM per guess, making GPU-based attacks impractical (GPUs have limited memory per core). Adjust upward based on your server capacity — the goal is ~250-500ms per hash on your hardware. Our hash-generator tool shows how different algorithms and parameters affect computation time.
Migration path: if you're currently using bcrypt, don't rush to migrate. Bcrypt with cost 12+ is still secure. If you're using MD5 or SHA-256 (with or without salt), migrate immediately. The standard approach: on next login, verify against the old hash, then re-hash with Argon2id and store the new hash. Users who never log in again keep the old hash — accept this or force a password reset.
Multi-Factor Authentication (The Real Security Layer)
Here's an uncomfortable truth: even perfect password security best practices can't protect against phishing. If a user enters their 128-bit-entropy password into a fake login page, it's compromised. Multi-factor authentication (MFA) is the only defense against credential theft. Google reported that adding SMS-based 2FA blocked 100% of automated bot attacks and 96% of bulk phishing attacks.
The MFA hierarchy from weakest to strongest: SMS codes (vulnerable to SIM swapping — T-Mobile had 76 million records exposed in 2021), TOTP apps (Google Authenticator, Authy — secure against remote attacks but not real-time phishing), push notifications (Duo, Microsoft Authenticator — vulnerable to MFA fatigue attacks where attackers spam prompts until the user approves), hardware keys (YubiKey, Google Titan — phishing-resistant because they verify the domain).
FIDO2/WebAuthn passkeys are the future. They use public-key cryptography tied to a specific domain, making phishing mathematically impossible. The private key never leaves your device. Apple, Google, and Microsoft all support passkeys as of 2024. The adoption problem: users need to set them up, and not all services support them yet. For now, TOTP + a hardware key as backup is the practical recommendation.
For developers implementing MFA: never make it optional for admin accounts. Require it for any action that changes security settings (email, password, MFA itself). Store backup codes hashed (they're equivalent to passwords). Rate-limit MFA attempts to prevent brute-forcing 6-digit TOTP codes (there are only 1 million possibilities, and they're valid for 30 seconds).
Password Policies That Actually Work
Based on NIST 800-63B and real-world breach data, here's what a good password policy looks like in 2026: Minimum 12 characters (NIST says 8, but 12 gives meaningful brute-force resistance even with weak hashing). Maximum 64+ characters (never cap password length — bcrypt truncates at 72 bytes, but that's the algorithm's job, not your UI's). No composition rules. No rotation schedule. Block the top 100,000 breached passwords.
What to show users: a strength meter based on actual entropy estimation (the zxcvbn library by Dropbox is excellent — it accounts for dictionary words, keyboard patterns, and common substitutions). Show "weak/fair/strong" with specific feedback: "This password appears in a data breach" or "Adding 4 more characters would make this significantly stronger." Don't just show a colored bar with no explanation.
What NOT to do: Don't prevent paste in password fields (this punishes password manager users — the people with the best security practices). Don't limit character sets (allow Unicode — some users want passwords in their native language). Don't show "password requirements" as a checklist that users game with minimal effort. Don't email passwords in plaintext (use time-limited reset links instead).
For enterprise: implement breached-password screening at registration AND at login (passwords get breached over time). Log failed authentication attempts and alert on anomalies (10 failed attempts from different IPs targeting the same account = credential stuffing). Consider risk-based authentication — require MFA for logins from new devices or unusual locations, but not for the user's daily laptop.
The Uncomfortable Truth About Password Security
No password policy can fix the fundamental problem: humans are bad at randomness and good at taking shortcuts. The median user has 100+ online accounts and reuses passwords across most of them. Password managers solve this but have ~30% adoption among general users (higher among developers). Until passwordless authentication (passkeys, biometrics) becomes universal, we're stuck with passwords as a necessary evil.
The biggest risk isn't weak passwords — it's password reuse after breaches. The Collection #1 leak (2019) contained 773 million unique email/password pairs. If your users' passwords from other services end up in these lists, no amount of complexity requirements on your site helps. This is why breach screening (Have I Been Pwned integration) and MFA matter more than password strength rules.
My practical advice for individuals: Use a password manager (Bitwarden is free and open-source). Generate random 20+ character passwords for every site. Use a memorable passphrase (4-5 random words) as your master password. Enable MFA everywhere it's available, preferring TOTP apps over SMS. Check haveibeenpwned.com periodically. Accept that you'll need to reset passwords when services get breached — it happens to everyone.
For developers: Hash with Argon2id or bcrypt. Implement breach screening. Require MFA for sensitive operations. Don't invent your own password rules — follow NIST 800-63B. And please, stop storing passwords in plaintext. In 2026, there is no excuse. Every framework has a battle-tested auth library. Use it.