DEV Community: Amr Abumady

What the Revolut Breach Says About Storing Identity Documents Forever

Amr Abumady — Sun, 13 Sep 2026 06:34:33 +0000

Revolut confirmed this week that it sent customer passport scans and transaction records to attackers who impersonated a government agency with a forged legal request (Reuters, Sept 12). No server was hacked. No password was cracked. A human on the compliance side looked at a request that read like it came from law enforcement, and handed over the file.

This is the failure mode that's easy to miss when we talk about "data breaches." We spend enormous engineering effort on encryption at rest, encryption in transit, access logging, and SOC 2 audits, and then the actual leak happens because someone approved a request that looked legitimate enough. The data was sitting there, complete and exportable, waiting for exactly the right piece of social engineering.

The root problem isn't the process failure. It's that the data existed to be exported at all.

Most identity verification today follows the same shape: a site asks for a passport or ID scan, stores it (or a vendor stores it on the site's behalf), and keeps it indefinitely "in case we need it again" (for compliance, for support disputes, for re-verification). Every one of those stores is a future Revolut. The attacker doesn't need a zero-day; they need one convincing forged letter and one tired employee on a Friday.

We built ClientN around a different assumption: verification and storage don't have to be the same step.

When someone verifies as a real, unique human on ClientN, the ID/passport check and the face match happen once, and the raw documents aren't retained afterward: what persists is a cryptographic attestation, not the image. Each site the person then connects to gets a different anonymous ID (a CN- handle), scoped to that site, with no shared identifier a second party could correlate across services or exfiltrate in one shot. There's no central vault of passport scans sitting behind a support ticket queue for someone to social-engineer their way into, because the vault doesn't exist after the initial check is done.

This is a trade-off, not a magic fix. A site that genuinely needs an auditable copy of your ID for its own regulatory reasons (say, a bank) still needs to hold that copy. ClientN doesn't solve that problem, and it's not trying to be a KYC vendor for regulated finance. What it solves is the far more common case: sites that ask for identity verification purely to prove "this is one real human, not a bot or a Sybil farm," and then hold onto sensitive documents they never technically needed to keep. Passkey login for session security, a one-time Sybil-resistance check, an anonymous per-site ID, and nothing left over that a forged government letter could unlock.

If you're building anything that needs "prove you're a real, unique person" without needing "collect and retain their government ID forever," the demo is at clientn.com/demo and integration docs are at clientn.com/dev. Verified Human accounts start at $1/year during the launch window: clientn.com/signup.

Verified Human. Still Anonymous.

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

Amr Abumady — Fri, 04 Sep 2026 09:23:24 +0000

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:

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).
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.

ClientN Shield: Privacy-First Authentication for the Modern Web

Amr Abumady — Thu, 19 Mar 2026 13:04:32 +0000

Your Identity Shouldn't Be the Price of Admission

Every time you sign up for a service, you hand over your email, name, and personal data. ClientN Shield changes that.

What is ClientN Shield?

ClientN Shield is a privacy-first authentication platform launching H2 2026. It lets users sign in to any website without sharing personal information.

Key features:

Zero personal data shared with websites
Anonymous authentication that actually works
Your identity stays yours
Simple integration for developers

Try Our Privacy IQ Quiz

Think you know how your data is being used? Take our Privacy IQ Quiz and score 7+ to claim a free 3-month premium account!

Join the Waitlist

We're launching in H2 2026. Join the waitlist to be first in line.

What privacy challenges do you face as a developer? Let me know in the comments!