How long should a password actually be in 2026? The math, the myths, and why MFA is the real answer

Every January, someone publishes the "most common passwords of last year" list, the headlines write themselves (123456 is still on top, somehow), and the comment sections fill up with arguments about whether 12 characters is enough, whether you need a symbol, and whether the company that just made everyone change their password for the third time this year is doing the right thing. The arguments are usually sincere. They are also, in 2026, the wrong argument.

The honest summary of where account security actually sits today: password length has almost nothing to do with whether your account gets taken over. Length matters in exactly one scenario - an attacker has stolen the hashed password database and is trying to crack it offline - and even that scenario is increasingly handled by the site, not by you, through modern key-derivation functions. The scenarios that actually take over accounts in 2026 are phishing pages, infostealer malware, credential-stuffing from old breaches, and SIM-swap attacks on SMS codes. None of those care if your password is 8 characters or 80.

The thing that does stop them is a second factor. And the thing that is starting to replace passwords entirely - quietly, on the sites you use most - is the passkey. This article walks through the math behind the length debate, the reason forced password rotation and complexity rules have been formally retired by NIST and Microsoft, the realistic threat model for a normal person in 2026, and what to actually turn on this afternoon.

The math behind "how long is long enough"

The case for a long password rests on a single calculation: an attacker who has stolen a hashed password database tries to guess each password by running candidates through the same hash function and comparing. The longer and more random the password, the more candidates the attacker has to try. This is real. It is also a much narrower threat than it sounds.

A truly random 8-character password from the full keyboard (95 printable characters) has about 52 bits of entropy. A truly random 12-character one has 79 bits. A 16-character one has 105. Against a fast offline cracker running on consumer GPUs - the kind of rig that broke into the LastPass vaults from the 2022 incident - 52 bits is crackable in hours to days for a weak hash like unsalted MD5 or SHA-1, and effectively uncrackable for a properly tuned modern hash like Argon2id or bcrypt with a high cost factor. At 79 bits and above, even unsalted SHA-1 is out of reach for anyone short of a nation-state, and modern hashes are out of reach for everyone.

Two things follow from that. First, if a site is hashing passwords properly in 2026 (Argon2id, scrypt, bcrypt with cost 12+), a 12-character random password is already overkill for the offline-cracking threat. Second, if a site is not hashing passwords properly - if it stored them in plain text, or used MD5, or hashed without a salt - then no length you can realistically type will save you, because the attacker already has the plaintext or will have it within a week. Length is a useful insurance policy, but only inside a narrow band, and only against a threat that good sites have already mostly defused.

The catch is that almost no one types a truly random 8-character password. They type Summer2025! or Tr0ub4dor&3, both of which look strong to a length-and-complexity checker and are trivially guessed by a real cracker, because the cracker doesn't try every combination - it tries the dictionary, then the dictionary with common substitutions, then the dictionary with years appended, and so on. That is the actual reason length-and-complexity rules don't work: they measure the wrong thing.

Why NIST and Microsoft told everyone to stop forcing rotation

The US National Institute of Standards and Technology publishes the digital identity guideline that most large American organizations follow, SP 800-63B. The current revision and the draft of revision 4 are unambiguous about two old rules:

• Verifiers SHALL NOT impose composition rules - the "must contain an uppercase, a lowercase, a number, and a symbol" line that you see on most signup forms. NIST's own analysis is that these rules push users toward predictable patterns (Capital letter at the start, number and exclamation mark at the end) without raising real entropy.
• Verifiers SHALL NOT require periodic password changes. Forced rotation should only happen when there is evidence of compromise (a breach, a credential found in a stuffing list, a suspicious sign-in). Time-based rotation, NIST writes, leads to weaker passwords because users pick stems they can increment.

Microsoft removed the 60-day expiration policy from the Windows 10 security baseline in 2019, called it "an ancient and obsolete mitigation of very low value", and published the same reasoning: humans cope with rotation by picking predictable transformations of their old password, which an attacker who has the old one will guess on the first try. The UK National Cyber Security Center published almost identical guidance in 2016 and has not moved off it since.

None of this is a fringe position. It is the formal, written-down advice of the agencies whose job is to make this call. The reason it has taken so long to filter into corporate IT is partly that compliance frameworks like old versions of PCI-DSS explicitly required 90-day rotation, and changing those frameworks is slow. PCI-DSS v4.0 has now caught up: the rotation requirement is gone if the organization is doing continuous monitoring of the account.

The sticky-note problem, with receipts

The most cited paper on this is Cormac Herley's "So Long, And No Thanks for the Externalities" from 2009, which made the then-heretical argument that users rejecting security advice is often rational - the time cost of following the advice exceeds the expected loss from ignoring it. Florencio and Herley followed up with measurements of real password behavior at scale inside Microsoft. Their consistent finding: users have a fixed cognitive budget for passwords, and every rule you add to one account comes out of the budget for another.

That budget is what explains the sticky note, the Excel sheet on the desktop called passwords-new.xlsx, the same password reused across the work VPN and a forum someone signed up to in 2014, and the autumn-spring-winter-summer cycle. None of those behaviors come from users being lazy or stupid. They come from policies that demand more than the human memory system can supply, applied uniformly to a thirty-account digital life. When the policy relents - when a strong password can stay in place for years and the user only has to remember one of them - the sticky note goes away on its own.

The practical version of this for you: pick one strong passphrase for your password manager, let the manager generate everything else, and stop worrying about whether the Netflix password is "complex enough". It is random and 20 characters long, because the manager made it so, and you will never type it.

The real threats in 2026, in the order they actually take over accounts

1. Phishing

A convincing fake login page, usually delivered by SMS or email, captures your username, your password, and - if the kit is modern - the time-based one-time code you type from your authenticator app, in real time, by relaying the request to the real site. The off-the-shelf phishing-as-a-service kits (EvilProxy, Tycoon, NakedPages) have done this for years. They do not need to crack anything. You hand them the password.

Length does not help. Complexity does not help. Rotation does not help - the attacker uses the password within minutes. The defense is a factor the phishing page cannot relay: a passkey, or a FIDO2 security key, both of which sign a challenge bound to the real domain. The fake domain gets a signature for the fake domain, which the real site rejects.

2. Infostealer malware

A user downloads a cracked game, a fake video-conference installer, or a "free" Photoshop, and an infostealer (RedLine, Lumma, Vidar, Stealc) reads every browser-saved password, every session cookie, and every crypto wallet on the machine, then ships them to a Telegram channel. The volume is enormous - millions of fresh stealer logs a month feed the underground market.

Length and complexity again make no difference; the stealer reads the plaintext out of the browser's password store. The defenses that work: not saving passwords in the browser (use a manager that requires re-authentication), and a second factor the malware does not have - a hardware key plugged into a USB port, or a passkey on a separate phone. Session cookies are the harder problem: a stolen session cookie can bypass MFA until the session expires, which is why short session lifetimes and device-bound sessions matter.

3. Credential stuffing

Have I Been Pwned tracks roughly 14 billion breached credentials at the time of writing. Attackers take those username-password pairs and try them against every site they can think of. If you reused the password from the 2016 LinkedIn breach on your bank, the attack is one HTTP request away. There is no cracking involved. There is no skill involved. It is a script.

The defense is "don't reuse passwords". Which in practice means "use a password manager", because no human reliably keeps 200 unique passwords in their head. A second factor on the important accounts catches the cases where the password did leak.

4. SIM-swap and SS7

An attacker convinces (or pays) someone at your mobile carrier to port your number to their SIM, then triggers an SMS-based password reset on your accounts. The SS7 variant exploits the routing protocol the global phone network runs on and intercepts the SMS without involving the carrier's customer service at all. Both are well documented and ongoing.

The defense is to not rely on SMS for the recovery path. Use an authenticator app, a hardware key, or a passkey. Where a site forces SMS for recovery (some banks still do), at least set up a carrier-side port freeze and a PIN on the mobile account.

What to actually turn on

In rough order of impact, here is the realistic stack for a normal person in 2026.

1. A password manager. Bitwarden and 1Password are the common picks for cross-platform; Apple Passwords is fine if you live entirely in the Apple ecosystem; KeePassXC if you want fully local. Set a long master passphrase - four to six unrelated dictionary words, the kind of thing you can type from muscle memory after a week. Our password generator will produce a passphrase like that without sending it anywhere.
2. A second factor on the manager itself. A hardware security key (YubiKey, Token2, Google Titan) is the strongest option; an authenticator app is a fine fallback. SMS is not a serious second factor for the thing that holds every other password.
3. Passkeys, wherever the site supports them. Google, Microsoft, Apple, GitHub, PayPal, Amazon, eBay, Adobe, Best Buy, Kayak, and most of the password-manager vendors themselves now offer them. Enrol two devices when the site allows it, so losing one phone does not lock you out. The site passkeys.directory keeps a running list of who supports them.
4. Authenticator-app MFA on the rest. When a site does not offer passkeys, an authenticator app (Aegis on Android, Raivo or 2FAS on iOS, Authy if you want sync, the password manager itself if it handles TOTP codes) is the next-best thing. Hardware keys with the OATH-TOTP slot are an upgrade for the high-value accounts.
5. Email and phone as the recovery weakest links. Your email account is the master key to everything that resets through email; protect it like the master password. Your phone number is the master key to anything that resets through SMS; remove SMS from everything that lets you.
6. Stop changing strong passwords on a schedule. If you are an IT admin reading this, kill the 90-day rotation policy on accounts that have MFA enabled. Rotate on evidence of compromise, not on the calendar. NIST, Microsoft, and the NCSC will all back you up in writing.

What about the "passwords are dead" headlines?

Passwords are not dead. They are slowly being demoted from "primary defense" to "fallback secret that backs up the real defense". The real defense on a passkey-enabled site is the device you unlock with your face or fingerprint. The real defense on a hardware-key-enabled site is the metal token plugged into your laptop. The password sits behind both of those, useful for account recovery on a new device and irrelevant the rest of the time.

The places that move slowest are exactly the ones that will keep password-only logins around for years: small SaaS tools, regional banks, government portals, and any internal corporate system written more than a decade ago. For those, the realistic plan is unchanged from the last five years - manager-generated random password, a TOTP app for the second factor, and a calm acceptance that this is the floor, not the ceiling.

The argument worth having in 2026 is not "should my password be 12 or 16 characters". It is "does this account have a second factor, and if not, why not". Get that one right and the length question answers itself: long enough that a manager generated it, short enough that you will never have to type it.

One last note on the tools on this site

Privvert's password generator runs entirely in your browser - the candidate passphrases never touch a server, ours or anyone else's. The same goes for the hash tool if you want to see what your password looks like through Argon2 or bcrypt, which is occasionally useful for understanding what a site is storing about you. The broader argument for local-only tools is on the privacy page; the rest of the practical guides are on the blog.