Why I Killed the Password on Every Project I Ship
I made a quiet architecture decision this year and then turned it into a rule: no project I ship gets a password field. New builds, old builds, side projects, client work — they are all moving to magic links. Not because magic links are the most secure thing on the internet. They are not. It is because, for the way I actually build and maintain software, they win on the two things that were quietly costing me the most: maintenance and adoption.
Here is the reasoning, the data I checked it against, and an honest accounting of where the trade-off loses.
The password problem isn't a user problem. It's structural.
We love to blame users for bad passwords. The data says the problem is the mechanism itself.
- 65% of people reuse passwords across multiple sites — only about a third use a unique one everywhere (Google / Harris Poll, 2019). And they know better: a LastPass study found 91% understand reuse is risky and 66% do it anyway.
- The average person now juggles roughly 120 personal passwords, plus around 70 more for work (NordPass, 2026). Nobody manages that honestly. They reuse, they write them down, or they live in the "forgot password" flow.
- Credential abuse is the single most common way attackers get in — 22% of breaches, ahead of vulnerability exploitation and phishing (Verizon 2025 Data Breach Investigations Report). The same report puts the human element in 60% of breaches.
- Stolen or compromised credentials are the costliest breaches to clean up, taking roughly ten months to contain (IBM Cost of a Data Breach, 2024, which pegged the global average breach at $4.88M).
Read that again: the thing I was building into every app — a stored, reusable secret — is the number-one way accounts get compromised. As an engineer, that reframes the password field entirely. It is not a feature. It is a liability I am choosing to host.
The maintenance tax nobody puts on the invoice
Every password field I ship drags a whole subsystem behind it:
- Secure hashing, plus a sane upgrade path as algorithms age
- A password-reset flow — itself a security-sensitive surface, and ironically a common attack path
- Rate limiting, lockouts, and (per current guidance) checking new passwords against known-compromised lists
- A credential database that is now a permanent target I have to defend forever
Even NIST has quietly conceded how broken the old model is. The latest digital identity guidelines (SP 800-63B, 2025) tell verifiers they SHALL NOT force periodic password changes and SHALL NOT impose composition rules like "one symbol, one capital" — the exact rules we spent a decade coding into every signup form. The rituals we built were never really helping.
And the support cost is real money. Forrester has put large organizations at up to $1M a year just handling password resets, and Gartner has estimated that somewhere between 20% and 50% of help-desk calls are password resets. I run a small shop — I do not have a help desk — which means that cost lands directly on me, usually at the worst possible time.
The adoption tax is even worse
The maintenance cost I could grind through. The adoption cost is the one that actually changed my mind, because it shows up before someone is even a user.
- One in three online purchases is abandoned at checkout because the shopper can't remember their password (Mastercard / University of Oxford, 2017).
- 25% of people would walk away from a cart over $100 rather than reset a password (Beyond Identity, 2021).
- 78% of people had to reset a forgotten password in the previous 90 days (HYPR, 2019).
Every one of those is a person who wanted what I built and bounced at the door I installed. For a founder watching activation numbers, "forgot password" is just a politely worded churn event.
Why magic links, specifically
A magic link is simple: you type your email, I send you a signed, time-limited link, you click it, you are in. Nothing to create, forget, reuse, reset, or — on my side — store.
That last part is the engineer's win. There is no password database to breach, because there are no passwords. OWASP treats a stored password file, even a properly hashed one, as a standing liability. Magic links delete that liability outright. I am not defending a credential store I do not have.
The pattern is not exotic, either. Notion, Slack, Substack, and Tumblr all let you sign in with nothing but an emailed link or code. And the broader industry is sprinting away from passwords: Okta's 2025 telemetry showed phishing-resistant sign-ins up 63% year over year, and the FIDO Alliance found 87% of US and UK enterprises are deploying passkeys — with 77% reporting fewer help-desk calls afterward.
What I have seen across my own projects matches the direction of that data: signups complete more often, and the steady drip of "I'm locked out" and password-reset requests basically stopped. I am not going to dress that up with a precise conversion percentage — I do not trust the viral case-study numbers floating around, and most of them trace back to vendor blogs with no primary source. But the trend on my side has been clear enough to make magic links the default.
Passwords vs. magic links vs. passkeys — honestly
I want to be precise about what I am claiming, because it is easy to oversell this. Magic links are not the most secure option. Passkeys are. Here is the actual trade-off space:
| Dimension | Passwords | Magic links | Passkeys |
|---|---|---|---|
| Stored-credential attack surface | Large — the password database is a permanent target; credential abuse is the #1 breach vector (Verizon, 2025) | None — nothing to store or steal | None — only a public key is stored |
| Phishing resistance | Weak — reusable and harvestable | Weak to moderate — not origin-bound, can be relayed (NCSC) | Strong — origin-bound, private key never transmitted (NCSC) |
| Signup / login friction | High — 1 in 3 abandon checkout on a forgotten password (Mastercard / Oxford, 2017) | Low — nothing to create or remember; one email round-trip | Lowest once enrolled — ~40% faster sign-in (Google); enrollment is the hurdle |
| Maintenance for me (the builder) | High — hashing, reset flow, breach-list checks, a credential DB to defend | Low — no password storage, no reset flow | Moderate — newer, with trickier enrollment and recovery edge cases |
| Support burden | High — up to $1M/yr per large org on resets (Forrester); 20–50% of help-desk calls (Gartner) | Low — no resets; the failure mode is email delivery | Low — 77% of enterprises saw fewer help-desk calls (FIDO, 2025) |
| Account recovery | "Forgot password" — itself the weak link | Tied to inbox access — email becomes the single point of failure | The hardest part — device loss and sync-ecosystem dependence |
| Works offline / no email | Yes | No — needs email delivery | Yes — local biometric or PIN once enrolled |
| Industry trajectory | NIST relaxing the old rules, not deprecating | Common (Notion, Slack, Substack); a pragmatic middle ground | Where the industry is pushing — 15B+ accounts, 87% of enterprises rolling out (FIDO, 2025) |
Where this loses — and why I'm doing it anyway
I am not going to pretend magic links are free of downsides:
- Your email becomes the single point of failure. Whoever owns the inbox owns the account (WorkOS). With passwords, the account is at least one factor removed from the inbox.
- Magic links aren't origin-bound, so they can be phished or relayed in an attacker-in-the-middle setup. Passkeys can't — the credential is tied to the origin and the private key never leaves the device (UK NCSC). That is a genuine security gap, and it is the main reason I refuse to call this the "most secure" choice.
- Email gets in the way. Links land in spam, add latency, and overzealous corporate security scanners sometimes click the one-time link before the human does and break the login (Stytch). WorkOS thought enough of these problems to deprecate its own magic-link product.
- Cross-device friction. Request on a laptop, open on your phone, and the laptop session can be left stranded.
So why ship it? Because for my context — solo and small-team products where I own the whole stack, and the alternative is a password field I have to secure forever — the math favors magic links today. They remove my single largest stored-credential liability and the single biggest signup drop-off, and they cost me almost nothing to maintain. Passkeys are where I expect to land eventually; the enrollment and recovery story is still rougher than I want to put in front of a brand-new user, so I treat magic links as the pragmatic front door and passkeys as the upgrade path.
That is the honest version. Not "this is the best authentication method," but "this is the trade-off that is working for me — less to maintain, better adoption — and here is exactly where it doesn't win." If you are building something today and dreading the password subsystem, that might be reason enough to skip it too.