DEV Community

Amr Abumady
Amr Abumady

Posted on

Why websites replaced passwords with sign-in codes — and what comes after

There's a recurring question on Hacker News that keeps resurfacing: why do so many websites now email you a sign-in code instead of asking for a password? It's a fair question, and the answer says a lot about where web authentication is heading — and about a gap almost nobody is solving.

The short version: passwords were always the wrong primitive

A password is a shared secret. You know it, the site stores a hash of it, and every breach is a race between their hashing and someone's GPU. Email codes ("magic codes") sidestep the stored-secret problem: the site never keeps anything you'd mind leaking, and the proof of identity is "you can read this inbox right now." That's genuinely better than a reused password. It's also why they spread so fast — they're cheap to bolt on and they kill the top support ticket ("I forgot my password").

But a code in your inbox is still a bearer proof. Anyone who can read that inbox — a forwarded email, a hijacked mail account, a shoulder-surfed screen — can sign in as you. It moves the weak link from the password to the mailbox; it doesn't remove it.

Passkeys are the actual fix

Passkeys (WebAuthn discoverable credentials) replace the shared secret with public-key cryptography bound to your device and unlocked by your fingerprint or face. The site stores a public key; the private key never leaves your hardware. There's nothing in the database worth stealing, nothing to phish, and nothing to type. This is the endpoint the "sign-in code" trend is stumbling toward: no password, no bearer token sitting in an inbox.

If you build web apps, this is the part worth internalizing: the industry has quietly agreed that the login secret should not be something a human types or an attacker can copy. The only debate left is the packaging.

The gap nobody talks about: "who" vs. "unique human"

Here's what neither passwords nor magic codes nor even passkeys solve on their own: is this a real, unique person — without me having to collect their identity?

Most sites answer that by hoarding data. They demand your email, your phone, sometimes your ID, and they store all of it so they can de-duplicate accounts and fight bots and Sybil attacks. You end up with the worst of both worlds: the site carries a breach liability it never wanted, and you hand over identifying data to every service you touch.

That's the problem we've been building ClientN around. The idea is to split the two jobs that authentication usually fuses together:

  1. Prove you're a unique, real human — once. We verify a person with a passkey plus a layered "Verified Human" check (an email code, a card check, and an optional ID/passport + selfie face-match done on our own servers, encrypted at rest, never shared).
  2. Give each site a different anonymous identifier for that person. A site sees a stable CN-… id that's unique to that site and reveals nothing else. The same human logging into two sites gets two unrelated ids, so the sites can't correlate you — but neither can be fooled into thinking one person is a thousand.

The login flow itself is not an OAuth redirect that leaks your identity to a broker. The site asks ClientN for a one-time session; you confirm on clientn.com with your passkey ("Do you want to sign in to example.com?"); we send the site back a signed, per-site anonymous id. The site gets "verified, unique, human" without ever getting you.

Verified Human. Still Anonymous.

That's the whole thesis in four words. The sign-in-code trend is a symptom of an industry that knows passwords are finished but hasn't decided what "identity" should mean online. Our bet is that the right answer is less identity, cryptographically proven — not more of it, stored in more databases.

If you want to see it working, there's a live demo forum whose only login is "Sign in with ClientN": https://clientn.com/demo. If you run a site and want to add it, the integration is a single <script> tag plus one signed callback — docs at https://clientn.com/dev. And if you just want your own Verified Human account, we're in early access at a $1/year launch price: https://clientn.com/signup.

Passwords are ending. The interesting question is what we replace them with — and whether we finally stop treating "prove you're human" as an excuse to collect everything about you.

Top comments (0)