A widely shared post titled "Passkeys are a trap. Do not use them" climbed the Hacker News charts last week, advising non-technical users to abandon passkeys in favor of TOTP codes and passwords. The post's central thesis: passkeys support attestation, a mechanism that lets websites demand cryptographic proof of your authenticator, and sites will gradually tighten this dial until only approved software on approved operating systems can log in. The author imagines a world where LineageOS is locked out, ad-blockers are detected, and Netflix password-sharing is impossible. The rebuttal, written by someone who built and open-sourced a passkeys library, deployed passkeys on their own SaaS platform, and created WhyNoPasskeys.com, is methodical. The most important factual correction: the passkeys most people actually use — synced passkeys stored in iCloud Keychain, Google Password Manager, 1Password, or Bitwarden — return no attestation statement at all. A site can ask, but it gets back nothing. Any consumer website that required attested passkeys tomorrow would instantly lock out nearly all its users. The official guidance for consumer sites has been to not request attestation for years. The viral post also misdescribes what attestation actually does when present. WebAuthn attestation reveals the make and model of the authenticator via its AAGUID, backed by a vendor certificate chain. It says nothing about your operating system, browser, extensions, whether your phone is rooted, or your firmware version. The dystopian scenario described — OS-level surveillance gated through passkey attestation — is not how the protocol works. Perhaps the most telling error: the original post recommends YubiKeys as a safe alternative because they "avoid OS-wide attestation." In reality, YubiKeys are precisely the authenticators that do attestation. Every YubiKey ships with a Yubico-issued attestation certificate, and enterprise attestation exists specifically so organizations can mandate approved hardware keys. The post's own recommendation steers readers directly toward the mechanism it warns against. The security tradeoff the viral post ignores is concrete and well-documented. TOTP codes are phishable. Phishing kits like Evilginx relay passwords and TOTP codes to the real site in real time, capturing sessions. This is not theoretical — it is the primary mechanism behind a large share of account takeovers today, as demonstrated in the Troy Hunt incident the author references. Passkeys are domain-bound; your browser will not present an example.com passkey to examp1e.com. The original author even concedes this in an addendum but still tells readers to avoid passkeys — a recommendation that trades phishing-resistant credentials for phishable ones. The underlying concern about attestation creep is not entirely without merit as a future policy question. If consumer sites began requiring specific authenticators, that would be worth organized pushback. But this has not happened, the largest providers do not support it for consumer authentication, and abandoning passkeys today in anticipation of a hypothetical future provides no protection. It simply removes the strongest phishing defense available to ordinary users right now. The author's conclusion is straightforward: keep using passkeys everywhere they are offered, store them in a password manager you trust, choose a provider that supports credential portability, and push back loudly if attestation requirements ever creep into consumer logins. The security calculus favors the phishing-resistant option that exists today over the phishable alternative.
