Zero. That is how many times the word "phish" appears in Passkeys are a trap. Do not use them., a nearly 5,000-word essay that has drawn 688 points and close to 400 comments on Hacker News since Sunday. Its subtitle names the audience: non-technical citizens of the web. Its advice to them is in the title.
The essay is right that passkeys come with a dial. It is wrong about whose hand is on it. Remote attestation, the mechanism it fears, lets a website demand cryptographic proof that a passkey lives in approved hardware and software. But that demand is made at registration, by the site, and when the site says nothing the WebAuthn default is "none". Telling ordinary users to walk away from passkeys over a setting they don't control sends most of them back to the credentials phishing already beats, to guard against a policy the people building sign-up forms can simply decline.
What passkeys buy is domain binding. The browser produces a passkey's signature only for the site that created it, so a lookalike page collects nothing it can replay. Passwords and authenticator codes work the other way. They are yours in exactly the sense the essay prizes: store them anywhere, type them anywhere. That is the problem.
The control the essay wants to keep is the same control a phishing page borrows.
Its recommended alternative shows the gap. The essay calls TOTP "a great solution" and reassures readers that if a code leaks in a photo of your desk, "you're only at risk for a couple of minutes until the code expires." A couple of minutes is generous. An adversary-in-the-middle kit like Evilginx sits between you and the real site, passes your password and code through as you type them, and keeps the session cookie the real site hands back. The code expires in thirty seconds. The session doesn't.
The author knows this. It's in an addendum, after the footnotes:
And I haven’t even pointed out one of their best security features: they are (in most use cases) domain-bound, meaning they are resistant to what are called Man-In-The-Middle attacks.Passkeys are a trap
That property is most of the case for passkeys, and it gets one sentence.
The strongest part of the essay deserves to be taken straight. Attestation is in the standard, and the freedom it threatens is real: the author generated a passkey with open-source software, emailed it to a friend, and now both of them can sign in. Netflix would like that to stop, and attestation is one way to stop it. It is also a blunt one. As one commenter points out, a site can only demand attestation when a passkey is created, never retroactively; the browser asks the user's permission when a site requests it; and Apple's passkeys don't support it. A consumer site that requires attestation is announcing at sign-up that it won't take iPhones. That is a loud, expensive decision, not the quiet, gradual tightening the essay predicts.
Which is why the essay is addressed to the wrong readers. The people holding the dial are technical: whoever writes the call that creates the passkey. WebAuthn even has an "enterprise" setting, described as intended for controlled deployments where an organization ties registrations to specific authenticators. For an internal tool on company laptops, that is a reasonable thing to want. For a consumer sign-up, asking for attestation means choosing which phones your customers are allowed to own. The essay's objection was never to the credential. It was to the scope of a policy, and scope is a decision builders make, one form at a time.
Zero mentions of phishing. One addendum. The dial is real, and it ships set to none. Leave it there.