Everything I Own, Owned: The Identity Cascade Problem

What happened

A post titled *Everything I Own, Owned* hit the Hacker News front page at 840 points — the kind of number reserved for stories that make thousands of engineers quietly open their password manager and check something. The author walks through a cascade compromise: one initial foothold, then a chain of recovery flows and trust relationships that turned a single breach into a total loss of identity. Email, cloud storage, financial accounts, connected devices, secondary providers — all gone, in the order dictated by which service trusted which other service.

The specifics vary from victim to victim, but the shape rarely does. It almost never starts with a broken cryptographic primitive or a novel zero-day. It starts with a recovery flow — the same flows engineers design to be forgiving because support tickets are expensive and users forget things. Once the attacker owns the recovery channel, they don't need to break anything else. They just click "Forgot password?" on every service in your life and let the system hand them the keys.

The HN comment section did its usual thing: half the thread swapped horror stories, the other half posted their own hardening checklists. Between the two, a clear picture emerged of a class of failure that the industry has known about for a decade and still refuses to design around.

Why it matters

The interesting question isn't "how did this person get pwned." It's why the pattern is so reproducible. Modern identity architecture is a directed graph of trust relationships that most people — including most engineers — have never actually drawn out. Your GitHub account trusts your email. Your email trusts your phone number for 2FA reset. Your phone number is defended by a call-center rep at a telco who is measured on average handle time. The strength of your entire identity graph is the strength of its weakest recovery path, and that path almost always terminates at a human being with a quota.

SIM swap is the most famous version of this attack, but it's just one edge in the graph. There are others: security questions that Google can answer for the attacker, notarized letters that overworked support teams accept at face value, OAuth apps you authorized in 2019 and forgot about, backup email addresses on defunct providers that anyone can now re-register. Each is a legitimate feature. Each is also a vulnerability the moment an attacker can reach it. Josh Bloch's line about APIs applies here almost word-for-word: every recovery flow is a public API, and every one you add is one you have to defend forever.

What makes this specific story resonate is that the victim wasn't naive. These posts almost never come from people who were reusing `password123`. They come from people who thought they had done the reasonable thing — TOTP on the important accounts, a password manager, unique passwords — and discovered that "reasonable" is a decade behind the attackers. The threat model most people carry in their heads is a script kiddie guessing passwords. The actual threat model is a small team with a phishing kit, a burner LLC to spoof identity documents, and enough patience to unwind three layers of recovery flow.

There's also a structural point the post gestures at without naming: the platforms have offloaded the cost of failure onto users. When your Coinbase or your Gmail is compromised, the recovery process is designed to protect the platform from liability, not to restore you. You will fill out forms. You will send in photos of your ID to the same address the attacker is now monitoring. You will wait. In the meantime, the attacker is emptying the account. This asymmetry — platform-friendly recovery, user-hostile recovery — is a policy choice, not a technical constraint.

What this means for your stack

For engineers, there are two orthogonal takeaways: how to harden your own footprint, and how to design systems that don't recreate this failure for your users.

On the personal side, the checklist is short and mostly boring. Passkeys or hardware security keys on your email account, first — before anything else. Your email is the master credential; every service treats it as ground truth. Two YubiKeys (one primary, one in a drawer) costs less than a nice dinner and eliminates the entire phishing-based attack surface. Second: create a separate, offline-registered recovery email that is used for nothing else, receives no marketing, and whose existence is not discoverable. Third: remove your phone number from every account where it functions as a 2FA reset path — the telco is not your friend here. Fourth: audit connected OAuth apps quarterly. Most people have granted broad OAuth scopes to at least one service they no longer use, and every one of those is a persistent backdoor into their primary account.

On the design side, if you're building auth today, the honest posture is that recovery flows are the product. Treat them with the same rigor as your login flow. Rate-limit them. Require multiple independent factors, not the same factor twice. Notify users on a separate channel when recovery is initiated, with a meaningful cooldown before it takes effect. Log everything. And — the part most teams skip — actually test what happens when a support agent is handed a plausible-looking impersonation attempt. If the answer is "they'd probably approve it," you have a P0 that isn't in your bug tracker.

The passkey rollout across the major providers over the last two years has quietly made the phishing problem tractable in a way it hasn't been since we invented passwords. If your service still doesn't support passkeys in 2026, you are actively contributing to the next version of this story.

Looking ahead

The individual story will fade off the front page in a day. The pattern will not. As long as identity graphs are stitched together from OAuth, SMS, and support-ticket discretion, cascade compromises will remain the most productive attack vector against high-value individuals — and "high-value" now includes any engineer with commit access to a package a million people depend on. The right response is not more security theater at the login prompt. It's shorter trust graphs, hardware roots, and recovery flows designed by someone who has read a phishing transcript.