Password Breaches Only Matter If You Have Passwords

Every year, another billion credentials leak.

The industry's response has been remarkably consistent for two decades. Longer passwords. More character classes. Mandatory rotation. Breach-corpus checking. Slower hashing algorithms. Multi-factor authentication layered on top.

Every one of those is a genuine improvement. I'm not arguing against any of them. But notice what they share: each one assumes passwords continue to exist. They're all defenses of an asset. None of them question whether you should be holding the asset in the first place.

That's worth sitting with, because it's the kind of assumption that becomes invisible once everyone's spent twenty years optimizing inside it.

The thing that makes passwords structurally hard

A password is a shared secret. That's the whole problem, and it's not fixable by making the secret longer.

For a password to work, both parties must know it. The user knows it. Your system knows it — or knows something derived from it, which is why we hash. That shared-ness produces a set of consequences that no amount of policy tuning eliminates:

You have to store something. Hashing is the right answer and it's genuinely good — bcrypt, scrypt, and Argon2 with sensible work factors make offline cracking expensive. But "expensive" is not "impossible," and it degrades. A work factor chosen in 2018 is worth meaningfully less against 2026 hardware. Your stored hashes are a depreciating asset that an attacker can work on indefinitely, offline, with no rate limiting and no detection, once they have a copy.

The user has to transmit it. Every login sends the actual secret to your server. TLS protects it in transit, which is fine — until it isn't. A reverse proxy that logs request bodies. An APM trace with over-broad capture. A debug dump written during an incident. The credential itself crosses the wire on every single authentication, and every place it lands is a place it can leak.

The user has to remember it, which means it's drawn from the space of things humans can remember, which is dramatically smaller than the space your entropy math assumes. This is why P@ssw0rd2026! satisfies every composition rule and falls to a rules-based cracking run in seconds: attackers don't guess uniformly across the character space, they guess using patterns derived from the last billion leaked passwords, and human beings are much more predictable than we'd like.

And it's phishable. This is the one that matters most, because it's the one that defeats everything else. A password is a static string the user can be tricked into typing somewhere. You can make it sixty characters long, rotate it hourly, and hash it with the most expensive KDF available — if a convincing login page asks for it, a meaningful fraction of users will type it in. Length doesn't help. Complexity doesn't help. Rotation doesn't help.

The uncomfortable arithmetic of layered defenses

Look at how the standard defenses actually perform against the failure that keeps happening.

Slow hashing raises the cost of offline cracking. Phishing bypasses it entirely — the attacker gets the plaintext, no cracking required.

Complexity rules raise theoretical entropy. Phishing bypasses them entirely.

Rotation limits the useful lifetime of a stolen credential. Phishing bypasses it, because the attacker uses the credential within minutes.

Breach checking prevents reuse of already-leaked passwords. Phishing bypasses it — the password you just handed over is brand new.

MFA is the one that actually helps, and it's why it's been the right advice for a decade. But the common forms are increasingly bypassed too: real-time phishing proxies relay the OTP as fast as the user types it, and push-approval fatigue attacks work because at 2am, on the eighth prompt, people tap approve.

So the pattern across twenty years of defenses is: each one raises the cost of a specific attack, and the attack that keeps working is the one that targets the user rather than the storage. That attack works because there is a static secret the user can be persuaded to reveal.

What passkeys actually change

The interesting thing about WebAuthn isn't that it's more convenient, though it is. It's that it removes the shared secret from the architecture entirely.

The user's device generates a keypair. The private key never leaves it — not to your server, not over the network, not into a log. Your server stores the public key, which is not a secret and never was. Authentication is a challenge-response: you send a random challenge, the device signs it, you verify the signature against the public key you already hold.

flowchart LR
    subgraph P["Password"]
        U1["User knows secret"] --> S1["Server stores hash of secret"]
        U1 -.->|"transmits secret\nevery login"| S1
    end
    subgraph W["Passkey"]
        U2["Device holds private key\n(never leaves)"] --> S2["Server stores public key\n(not a secret)"]
        U2 -.->|"transmits a signature\nover a one-time challenge"| S2
    end

Now walk the failure modes again.

Your credential database leaks. The attacker has a pile of public keys. Public keys are, by design, safe to publish — you could put them on a billboard. There is nothing to crack, no work factor to worry about, no algorithm that will look weak in eight years. The breach is genuinely uninteresting.

Someone logs your request bodies. They capture a signature over a challenge that has already been consumed. Replaying it fails.

A user gets phished. This is the important one, and the mechanism is worth understanding precisely, because it's not about user vigilance.

WebAuthn credentials are bound to an origin — the actual domain. When a user lands on c1avionx-login.com instead of the real domain, the browser doesn't consult the user's judgment. It looks for a credential scoped to that origin, finds none, and the flow simply doesn't produce a valid signature. The user cannot approve their way past this. There's no field to type the secret into, because there's no secret to type.

That's the structural difference. Password phishing defenses ask the user to detect a fake site. Passkeys make the browser refuse to cooperate with one. The first approach fails at some rate that depends on how tired and rushed people are. The second doesn't have a rate — it's a protocol property.

Someone reuses a credential across sites. They can't. Each keypair is generated per relying party. There is no cross-site reuse to exploit, which retires the entire credential-stuffing category for those accounts.

Where the argument has to stay honest

If the story ended there, everyone would have migrated already. They haven't, and the reasons are real.

Recovery is where the hard problem moved, not where it disappeared. If the credential is bound to a device, and the device is in a lake, you need a path back. Whatever that path is — an email link, a support call, a backup device — becomes the true security boundary of the account. It's entirely possible to deploy passkeys and end up with a phishing-resistant front door and a recovery flow secured by an email OTP, which means the account's real strength is the email OTP. Syncing passkey providers help a great deal here, and they also mean the credential's security now partly rests on the user's cloud account.

Enrollment has the same shape. Registering a passkey requires proving identity first — usually with a password, an email link, or an existing session. That bootstrap is a phishable moment inside an otherwise phishing-resistant system.

The environments where passwords are worst are the hardest to convert. Shared workstations in hospitals, factory floors, call centers, retail terminals — twelve people, one machine, no personal device, sometimes gloves. Every passkey assumption about a personal, biometrically-unlockable device breaks in those rooms, and those rooms are not rare.

And the long tail is long. Legacy applications, service accounts, integrations, that one vendor portal. Most organizations will run both models simultaneously for years — which means the password infrastructure stays, along with everything it requires.

That last point deserves emphasis, because it's where the argument is most often overstated. Deploying passkeys doesn't delete your password database. It starts a migration whose end state is deleting your password database, and the gap between those two things is measured in years. Until every account has migrated, you still have hashes to protect, rotation policy to argue about, and a breach that would still matter.

Why the framing still changes what you build

Even with all of those caveats, the reframe is worth adopting, because it changes which questions you treat as central.

Inside the password paradigm, the roadmap is a permanent hardening program: raise the work factor, tighten the policy, add breach checking, layer on MFA, tune the risk engine. Each cycle buys a real improvement and none of them ever finishes, because you're defending an asset whose fundamental properties don't change.

Outside it, the question becomes: what fraction of our authentications still involve a shared secret, and what's the plan to reduce it? That's a metric with a target. It can reach zero for a given population. It gives you a way to know whether you're making structural progress or just running faster inside the same loop.

The practical version, in order:

1. Instrument the ratio. What percentage of successful authentications used a phishing-resistant credential? Most organizations can't answer this, which means they can't tell whether the program is working.
2. Do the password fundamentals anyway. Argon2id or bcrypt at a current work factor, breach-corpus checking, no composition theater, no forced rotation absent a compromise signal. You need these for the entire transition period, which is long.
3. Solve recovery before you scale enrollment, not after. Otherwise you'll have built a strong front door with a weak side entrance and reported the front door to your board.
4. Segment honestly. Passkeys first where the assumptions hold — employees with managed devices, high-value customer accounts. Keep a considered fallback for the shared-terminal and legacy populations rather than pretending they'll convert.
5. Treat every remaining password as a scheduled deletion, not a permanent fixture to be hardened forever.

The line worth keeping

We have spent twenty years getting better at protecting a thing that is difficult to protect by construction. The improvements are real and the people who made them prevented an enormous amount of harm.

But the strongest defense of any asset is not holding it. You cannot lose credentials you never stored, and you cannot phish a secret the user does not know.

Password breaches only matter if you have passwords. Right now, almost everyone still does — and the useful work is not another round of hardening, but a credible plan for the day that stops being true.