Deepak Gupta

Why Passwords Fail (and What to Ship Instead)

Identity · intro · 8 min read · last reviewed 2026-08-15

A shared secret you can type is a secret an attacker can replay. What actually breaks, what does not fix it, and the order to replace passwords.

TL;DR

Most breaches still involve a stolen or reused credential. The password fails because memorable, unique, and secret cannot be true at once.
Stuffing, phishing, and the reset flow are the real holes. Complexity rules and 90-day rotation do not close them.
SMS or emailed codes on top of a password are not phishing-resistant MFA.
Ship a compromised-password check now, offer passkeys next to passwords, design recovery before you turn passwords off.
Passkeys with conditional UI are the default for new signups. Hardware keys are for admins.

Eighty-one percent of breaches still involve a stolen or reused credential. The password did not fail because users are careless. It failed because a shared secret you can type is a shared secret an attacker can replay, stuff, phish, and buy. I ran a CIAM platform that processed on the order of 200 million password resets a year. The reset was not a support feature. It was the product admitting the control did not work.

This is a teardown, not a eulogy. The password is still on most signup screens. The question is which part of it you can stop depending on this quarter, and what you put in its place. The longer cultural autopsy lives in The Password on Tech Graveyard. This page is the practitioner version.

What actually breaks

A password has to be memorable, unique, and secret. Those three requirements cannot be true at the same time for a human with 80 accounts. Every "fix" around the password is an admission of that.

Credential stuffing. Leaked username and password pairs from one breach are replayed against every other site. The user did nothing wrong on your site. Your login endpoint is just the next place that pair still works.

Phishing. A lookalike page captures the secret. SMS codes and emailed magic links fail the same way if the user types them into the fake form. Passkeys do not, because the authenticator binds the signature to the real origin.

Reset as a backdoor. The "forgot password" flow is often weaker than login: emailed links, knowledge questions, SMS, a support agent. Attackers skip the password and attack the recovery. If you ship WebAuthn without designing recovery, you have moved the hole, not closed it.

Your own storage. A hash is not a secret if the algorithm is fast. MD5 and unsalted SHA-1 are museum pieces. Even bcrypt is only as good as the cost factor and the rest of the stack. A database breach of password hashes is still a company-ending event because users reuse.

What does not fix it

Complexity rules. P@ssw0rd1 is not a secret. It is a regex the attacker already generates.
Rotation every 90 days. NIST dropped this for a reason. Forced rotation produces sequential passwords and sticky notes.
A password manager mandate for customers. Fine for your own team. You cannot require 1Password of a consumer signup.
"Just add MFA" on top of a password and call it done. If the second factor is SMS, you added a weaker channel. If it is a phishable TOTP code typed into the same fake page, you added friction without phishing resistance.

Password managers and breach monitoring buy time. They do not change the shape of the control.

What replaces it, in order

Control	What it actually does	When it is enough
Compromised-password check (Have I Been Pwned style)	Stops the worst reused secrets at signup	Minimum, ship this week
Passwordless OTP / magic link	Removes the stored secret; still phishable	Acceptable for low-risk consumer
TOTP or push MFA	Stops stuffing of password-only accounts	Interim for workforce and existing users
Passkeys / WebAuthn	Phishing-resistant, no shared secret	Default for new signups
Hardware key, device-bound	High assurance, higher lockout risk	Admin, finance, production

Do not wait for a "passwordless project." Add passkeys next to passwords with conditional UI. Prompt a second credential after the first succeeds. Design recovery before you turn passwords off. That sequence is in the passkeys guide. For a one-to-five person company, the solo-founder stack tells you to buy this from a managed provider rather than hash passwords yourself.

The honest timeline

Passwords will be on the internet in 2030. They will not be the default for any product that cares about account takeover. The companies still forcing a 12-character mix in 2026 are not being conservative. They are paying for resets, stuffing, and a support queue that a passkey prompt would have deleted.

If you have a consumer login and no passkey, that is the gap. If you have a B2B login and no SSO path, that is a different gap, covered in Add SSO. Do not confuse them.

Failure modes

Turning off passwords before recovery works. You will lock out the users you kept.
Shipping passkeys as a buried setting. Defaults win. Optional passkeys stay at single-digit adoption.
Keeping SMS as the fallback. You reintroduced the control you just replaced. See SMS MFA.
Hashing with a fast algorithm "for now." There is no later. Rotate now.
Treating a password manager rollout as the end state for customers. It is the end state for your own laptops, not for signup.

Key takeaways

The forgot-password flow is often weaker than login. Attackers skip the password and hit recovery.
A password manager mandate is for your team, not for consumer signup.
Optional passkeys stay at single-digit adoption. Defaults win.
Do not turn off passwords before a second credential and a recovery path exist.
Hashing with a fast algorithm 'for now' has no later.
SSO for B2B and passkeys for consumers are different gaps. Do not confuse them.

Frequently asked questions

Are passwords actually dying?: They will still exist in 2030. They should not be the default on any product that cares about account takeover. Passkeys win by being faster and phishing-resistant, not by a policy memo.
Is a password manager enough?: For your own employees, yes as hygiene. For customers, you cannot require one. Offer passkeys and stop storing a secret they have to invent.
Should I add MFA before passkeys?: Add a second factor that is not SMS, and add passkeys in parallel. MFA on a phishable code is interim. WebAuthn is the destination.
What is the first thing to ship this week?: A compromised-password check at signup and login, and MFA on every internal admin account. Then enroll passkeys beside passwords.
Why are password resets such a big deal?: They are often emailed links, SMS, or a support override, all weaker than the login you spent engineering on. Design recovery before you call the account passwordless.