For a package registry account, why is a passkey phishing-resistant but a TOTP code not?

A package registry account is not an ordinary login. Whoever holds a session on it can publish a version that resolvers everywhere will treat as the genuine continuation of a name people already trust. That makes the second factor on that account a supply-chain control, and it makes the *kind* of second factor matter more than the fact that one exists. ## What "a second factor" buys, and where it stops Multi-factor authentication exists because a password can be stolen and reused later - from a breach dump, a keylogger, or a password reused on a site that leaked. Any second factor breaks that: knowing the password a month from now is no longer enough. All the common options - SMS codes, TOTP apps, push approvals, hardware keys - do that much. What they differ on is a second attack: **real-time relay**. The attacker does not need your password for later; they need a session *now*. A maintainer receives a message about an urgent policy change, a takedown notice, or a security alert, linking to a page that looks exactly like the registry's login on a domain that reads almost right. That page is a proxy. Everything typed into it is forwarded live to the real registry, and everything the real registry sends back is rendered to the victim. This is adversary-in-the-middle phishing, and it defeats every factor whose output is a value a human copies. - **SMS**: the code is a value. It is also deliverable to whoever controls the phone number, which a SIM swap or a persuasive call to carrier support can change without touching any of the maintainer's devices. - **TOTP**: the code is a value, derived from a shared secret and a clock. Its short validity window is not a defence - a proxy uses it within seconds. The shared secret is also copyable at enrolment and often ends up backed up somewhere convenient. - **Push approval**: the "value" is a tap. The proxy triggers the real login, the real push arrives, and a maintainer who is in the middle of logging in approves it. Prompt-fatigue spam is the cruder version of the same trick. ## Why a passkey is different in kind A passkey is a WebAuthn/FIDO2 credential: a key pair created by an authenticator - a hardware key, a phone, or a platform secure element - and registered against a specific **relying-party ID**, essentially the registry's domain. Authentication is not a code; it is a signature over a challenge the server sent, and the browser will only ask the authenticator to sign for the origin the credential was bound to. Two consequences follow: 1. **Origin binding.** A lookalike domain is a different relying-party ID. The browser will not offer the registry's credential to it, so the proxy has nothing to relay. The maintainer cannot make the mistake, which is the whole point: the control does not depend on a tired human noticing one wrong character in a hostname. 2. **Nothing transferable exists.** There is no code on screen, no secret to read aloud to a "support agent", nothing to paste. The private key never leaves the authenticator, so even a compromised session cannot exfiltrate a reusable factor. That is what *phishing-resistant* means: not "harder to phish", but "the credential is structurally unusable on the wrong site". ## The parts a passkey does not cover Enrolling one and declaring the account safe is the common mistake. - **Recovery becomes the weakest path.** Recovery codes, a backup email address, or a support-driven reset can bypass the key entirely. Harden the mailbox with the same class of factor, keep recovery codes offline, and enroll a *second* key so that losing one does not force you down the recovery route. - **Automation credentials usually bypass interactive login altogether.** A long-lived publishing token used by a release job publishes with no second factor at all, because there is no human in the loop to challenge. Account hardening and credential scoping are separate problems, and solving one does not touch the other. - **Registry requirements often apply only above a popularity threshold.** A package can be installed enormously often as a transitive dependency while sitting below whatever bar triggers a mandatory-second-factor rule. - **One account is still one account.** The strongest factor on a sole personal owner still leaves a bus factor of one: nobody else can revoke, publish a fix, or respond if that person is unreachable. ## How to say this in an interview Frame it as a property rather than a product. For a publishing identity you want a factor that is **bound to an origin and produces no transferable value**, because the realistic attack is a live proxy rather than offline password reuse. Then name the residual paths - recovery, machine tokens, and sole ownership - because that is what separates someone who has read a policy page from someone who has actually hardened an account.