Password Security in 2026: Why Everything You Know is Wrong
Published January 25, 2026 · 12 min read
A friend called me last week, panicking because their company's IT team forced a password rotation. The new password had to be 12 characters, contain uppercase, lowercase, a number, a symbol, and not match the previous 24 passwords. They wrote it on a sticky note and put it on their monitor. Every security control that rule was supposed to enable, it actively broke.
That call is why I'm writing this. The password advice most people learned a decade ago is still being taught in 2026 corporate training, in government compliance documents, and on popular security websites. Most of it doesn't work. Some of it is actively harmful. And the recommendations that do work are simpler than the myths they've replaced.
I'm not a security researcher. I'm a developer who's had to think hard about authentication, who's read NIST's actual guidelines (not the "experts" interpreting them), and who's watched a lot of bad advice cause real problems. Here's what I actually tell people when they ask.
Where the Bad Advice Comes From
The password rules most people grew up with — eight characters, mixed case, a number, a symbol, change every 90 days — come from a 2003 NIST publication called "Authentication for the Digital Age" or, more colloquially, the "NIST password guidelines" that everyone misremembers. The actual document recommended those rules for systems that stored passwords in plain text and needed to make them harder to crack. That was a reasonable position in 2003.
What happened next is a case study in how requirements drift from their original purpose. Banks adopted the rules. Insurance companies adopted them. Compliance auditors started checking for them. And nobody updated the rules when the threat model changed.
In 2017, NIST published SP 800-63B, which explicitly walked back most of the 2003 recommendations. The new guidance says: minimum 8 characters (not 12), no forced rotation, allow all printable ASCII including spaces, check new passwords against breach databases, and prioritize length over complexity. In 2024, NIST doubled down with further refinements.
None of that matters if your IT department is still enforcing 2003 rules. The gap between current best practice and what's enforced in most organizations is years wide. That's the gap this article tries to close, at least for you personally.
What Actually Makes a Password Strong
Password strength is measured in bits of entropy — the number of guesses an attacker would have to try, on average, to crack it. Higher is better. The actual numbers that matter in 2026:
- 40 bits: Crackable in seconds on a single GPU. Don't use.
- 50 bits: Crackable in hours on a single GPU. Don't use for important accounts.
- 60 bits: Crackable in days on a single GPU, hours on a rig. Minimum for low-stakes accounts.
- 70 bits: Crackable in months. Good for most personal accounts.
- 80 bits: Crackable in years. Good for financial accounts.
- 100+ bits: Effectively uncrackable. Use for your master password and encryption keys.
How do you hit those numbers? It's just math. Each character of entropy adds a fixed number of bits depending on the character set:
- Random lowercase letters: ~4.7 bits per character
- Random lowercase + uppercase: ~5.7 bits per character
- Random lowercase + uppercase + digits: ~5.95 bits per character
- Random lowercase + uppercase + digits + symbols: ~6.5 bits per character
- English word from a 10,000-word dictionary: ~13.3 bits per word
Notice that the character set matters less than you think. A 16-character random lowercase password has 75 bits of entropy. A 12-character random mixed-case-with-symbols password has 78 bits. They're effectively the same strength. The 16-character one is easier to type and remember (or rather, easier to not need to remember because your password manager fills it).
Now compare to a "complex" password that follows the 2003 rules: Tr0ub4dor&3. That has maybe 30-40 bits of entropy, depending on how it's generated. It's "complex" but it's crackable in days. A 16-character all-lowercase random password is exponentially stronger, and it's "simpler."
Two Approaches That Work
Pick one. Don't mix them.
1. The Passphrase (for things you have to type)
Pick four or five random words from a dictionary of at least 10,000 words. The classic XKCD example is "correct horse battery staple" — four random words from a large dictionary, giving about 53 bits of entropy. That's strong enough for most uses, and it's actually memorable.
You can pick words with EFF's long wordlist, or you can let a tool generate them. Use five or six words for higher-value accounts. Add a number or symbol if a site requires it (most don't, despite the old advice). Don't pick quotes, song lyrics, or phrases from books — those are in attackers' dictionaries.
Use a passphrase for your password manager's master password. That's the one you actually have to type, multiple times a day. Everything else should be random — your manager fills it in for you.
2. The Long Random (for everything else)
Use a password manager (1Password, Bitwarden, KeePass, Apple Passwords, Google Password Manager — pick one) to generate 20+ character random passwords for every site. Don't try to type these. Don't try to remember them. Just let your manager handle it.
The strength of a 20-character random password with mixed case and digits: 119 bits. That's effectively uncrackable in any human timeframe. Even with a 1,000-GPU cluster running for a century, you wouldn't crack it. It's overkill for most uses, which is the point — the cost of overkill is zero, because you never have to think about it.
The pattern I follow: passphrase for the master password, random 20+ character passwords for everything stored in the manager. I have over 300 logins in my manager. I can name maybe 4 of the passwords. The rest are just noise that gets autofilled when needed.
Why Forced Rotation Doesn't Work
The 90-day rotation rule was based on a model where attackers had access to hashed passwords but not plain text. The idea was that even if an attacker got your hash and started cracking it, rotating the password every 90 days would put them back to square one. The math was reasonable. The assumption about attacker behavior was wrong.
Modern attackers don't crack passwords. They buy them. When LinkedIn got breached in 2012, 117 million password hashes leaked. When Collection #1 hit in 2019, 773 million emails and 21 million passwords hit the dark web. When RockYou2021 was posted, 8.4 billion passwords went up for sale. The actual cracking is done by criminals with GPU clusters, but the credential stuffing attacks against websites use these pre-cracked lists.
If an attacker has your password from a breach and you rotate to Summer2026!, then to Fall2026!, then to Winter2026!, you're not slowing them down. They're not even trying to crack the new password. They're using the old one from the breach list, or they're using the pattern they observed (you append the season and a number) to guess the new one.
NIST 800-63B is explicit: don't force rotation. It makes passwords weaker, not stronger. The exception is when there's evidence of compromise — then yes, change it immediately and figure out how they got in.
The Complexity Theater
Here's what an attacker trying to crack your password is actually doing:
If your password is in a known breach database (which most common passwords are), they don't need to crack it. They just look it up. Password1! is in every dictionary. So is Welcome2024. So is every common phrase with a single character or number substituted. The attacker tries the breach list first, then a dictionary of common transformations, then random combinations starting with the most likely patterns.
The "complex" requirements — one uppercase, one number, one symbol — don't help. Attackers know that pattern, and they test passwords that match it. Password1! with those rules satisfied has been in every dictionary for fifteen years. Tr0ub4dor&3 looks complex but follows predictable patterns (leet-speak substitutions, capitalized first letter, symbol at the end). It's still in dictionaries.
What actually defeats an attacker is being outside their dictionary. That means either being long enough that no dictionary covers you (16+ random characters) or being random enough that pattern-matching doesn't help (use a real RNG, not your brain). Both of those are easy with a password manager. Both are hard with the 2003 "complexity" rules.
What Protects You (In Order of Impact)
If you do nothing else, do these four things. Everything below is incremental improvements on top of these.
1. Use a password manager
Pick one. Use it. Don't share passwords between sites. Don't write them down on paper. Don't store them in a notes app. The manager generates, stores, and fills them. The only password you memorize is the master.
If you don't trust cloud-based managers (1Password, Bitwarden cloud, Google Password Manager), use a local one (KeePass, KeePassXC, Strongbox). The trade-off is convenience: cloud managers sync across devices automatically, local ones don't. Both are more secure than not using one.
2. Enable 2FA on important accounts
Email is the most important account. If an attacker controls your email, they can reset every other password. Enable 2FA on email first. Then banking, then social media, then anywhere else that supports it.
Use an authenticator app (Authy, Google Authenticator, 1Password, Bitwarden) or a hardware key (YubiKey, Titan, SoloKey). Avoid SMS 2FA when possible — it's vulnerable to SIM-swapping attacks where an attacker convinces your carrier to transfer your phone number to their SIM, then receives your 2FA codes. SMS is better than nothing, but it's the worst supported option.
3. Check for breaches
Go to haveibeenpwned.com. Enter your email. See which breaches it's appeared in. If any of those breaches include passwords you still use, change them immediately. Most password managers have built-in breach monitoring that will alert you automatically.
4. Use unique passwords everywhere
If you use the same password on two sites and one of them gets breached, the attacker has your password for the other site. This is how credential stuffing works. It's not a theoretical attack — it's the most common way accounts get compromised. The only fix is unique passwords per site, which is automatic with a password manager.
What I'd Tell Your Parents
For people who don't want to think about this much, here's the minimum viable password security:
Use a password manager. Apple Passwords (built into iOS and Mac) is good enough for most people. Google Password Manager (built into Chrome and Android) is good enough. 1Password and Bitwarden are good enough and a little more flexible. Pick one of these. Use it for everything.
Set a long master password. Four or five random words, easy to type, hard to guess. Don't reuse this password anywhere else. Don't write it down. Memorize it.
Turn on 2FA for email. Use an authenticator app, not SMS, if you can. If you can't, SMS is fine.
That's it. If you do those three things, you're more secure than 90% of internet users. You don't need to understand entropy. You don't need to know what NIST recommends. You just need to use a manager, a passphrase you remember, and 2FA on the account that can reset everything else.
Test Your Own Passwords
If you want to see how strong your passwords actually are, our Password Generator has a strength meter that shows the entropy of whatever you type. It also generates strong random passwords. It runs entirely in your browser — your passwords never leave your device, which is the only way this kind of tool should work. Don't trust a password checker that uploads your passwords to a server.
Type a password in, see how long it would take to crack. Then generate a 20-character random one and see the difference. If you do this once and internalize the math, you'll never write Summer2026! again.
The Hardware Key Argument
Most of this article is about passwords, but if I were setting up a high-value account in 2026, I'd skip passwords entirely for the second factor and use a hardware security key. A YubiKey, Google Titan Key, or similar FIDO2 device is a small USB or NFC token that proves your identity cryptographically. To log in, you tap the key. Phishing doesn't work against hardware keys because the key verifies the actual domain you're logging into, not just the credentials. Even if an attacker steals your password, they can't log in without the physical key.
Hardware keys cost $20-50. They last for years. They work across devices. They are the most secure 2FA option available to consumers, and the gap between hardware keys and authenticator apps is meaningful. If you have important accounts to protect (journalist, activist, system administrator, anyone with access to sensitive data), get two keys — one primary, one backup stored somewhere safe — and register both.
For most people, an authenticator app is fine. For the security-paranoid, a hardware key is worth the small investment. The phishing resistance alone justifies the cost.
The Biometric Question
Fingerprint and face recognition (Touch ID, Face ID, Windows Hello) are increasingly used to replace passwords entirely. The pattern: your device stores a biometric template locally, the device authenticates you, the device signs in to services using a stored password or token. The biometric never leaves your device.
Biometrics solve the "weak password" problem because users can't pick bad biometrics. They also solve the "password reuse" problem because each service gets a unique token. The downside: if your biometric is compromised (rare, but possible), you can't change it the way you change a password. And law enforcement can compel you to unlock with your face or fingerprint, but not with a password in most jurisdictions.
For personal devices, biometrics are a clear win. For shared devices, they don't make sense. For services where you need to log in from multiple devices, biometrics alone aren't enough — you still need a password or token that travels with you.
What I'd Tell a Company Building Auth in 2026
For the engineers and product managers reading this, here's what I'd say about designing authentication for a new product:
Don't enforce complexity rules. They're theater. Minimum length (12+), no maximum, allow all printable ASCII including spaces. Validate against breach lists. That's it.
Don't force rotation. Only prompt for password change on evidence of compromise. Forced rotation trains users to create predictable patterns.
Support password managers from day one. Make sure your login form works with 1Password, Bitwarden, Apple Passwords, and Google Password Manager. If a user can't easily use their manager, they'll use a weak password.
Make 2FA the default for new accounts. Don't make it opt-in. If you have to make it opt-in for some reason, at least show it prominently in onboarding. SMS 2FA is better than no 2FA; authenticator apps are better than SMS; hardware keys are best.
Use rate limiting and account lockouts. Brute force is still a thing. Lock accounts after 5-10 failed attempts, with exponential backoff. Use CAPTCHA after 3 failures to prevent automated attacks.
Hash passwords with a modern algorithm. Argon2id is the current best choice. bcrypt is acceptable. MD5 and SHA-1 are not. Use a unique salt per password (most modern libraries do this automatically).
Never log passwords. This should be obvious. I still see it in production code. Mask password fields in logs, error reports, and analytics. The cost of accidentally logging a user's password is catastrophic.
Plan for credential breaches. Not "if" but "when." Have a process for notifying users, forcing password resets, and revoking active sessions. Test this process before you need it.
The TL;DR for the TL;DR
If you read nothing else: use a password manager, set a long master passphrase, enable 2FA on your email and bank accounts, use unique passwords everywhere, don't rotate passwords unless compromised, and stop trusting advice from 2003. That's 90% of the security benefit for 10% of the effort.
The remaining 10% — hardware keys, paranoid threat models, custom password generators — is for people with specific elevated risks. If you're reading this article for general advice, the basic hygiene above is enough. Don't let security perfection become the enemy of security good.