Scott Helme 反驳「Passkeys 是陷阱」：attestation 只暴露设备型号，TOTP 才更危险
Scott Helme 逐条反驳「Passkeys 是陷阱」：同步 passkey 的 attestation 返回 none，可被实时中继的是 TOTP。
10 月 14 日，安全研究员、开源 WebAuthn 库 passkeys-php 作者 Scott Helme 发表《Passkeys are not a trap》，逐条反驳四天前热传的 Substack 文章《Passkeys are a trap. Do not use them.》。原文 10 月 11 日被提交到 Hacker News，拿到 1125 分、574 条评论；Apple 的 Passkeys 负责人 Ricky Mondello 也已在 10 月 12 日发帖，称它是「把阴谋论生拼硬凑的透明尝试」。Helme 的核心更正来自他维护 passkeys-php 的一手经验：同步 passkey 即使被网站请求 attestation，返回的也是 none。
要点
- 同步 passkey（iCloud 钥匙串、Google 密码管理器、1Password、Bitwarden）即使被网站请求 attestation，返回的也是 none，这是 Helme 写 passkeys-php 时的一手观察；消费级网站若强制 attestation，等于当场锁掉几乎所有用户。
- attestation 即便存在，经 AAGUID 暴露的也只有 authenticator 的厂商、型号和一条证书链，读不到操作系统、浏览器、固件版本或是否 root。
- 原文拿来当替代方案的 YubiKey，每枚出厂自带 Yubico 签发的 attestation 证书。
背景
10 月 10 日，化名「The Hack」的作者在 Substack 栏目 Non-Functional 发表《Passkeys are a trap. Do not use them.》。文章承认 passkey 技术上安全，但把 WebAuthn 标准比作「零件目录」，认为其中的远程 attestation 是特洛伊木马：等 passkey 普及，网站可以翻转策略、只接受经过认证的凭据，把 Linux、LineageOS、GrapheneOS 用户挡在门外，进而强制身份核验或内容扫描。文章的建议是留在密码加 TOTP 的组合上，或者改用 YubiKey 这类硬件安全密钥。次日它出现在 Hacker News，正反两方便在那个讨论串里交起锋来。
两个细节决定了这场辩论的成色。原文脚注 8 承认，自己此前把 authenticator data 里的 AT 标志位当成了远程 attestation 的指示位，而那个标志指向的是另一个同名的「attestation」概念；脚注 9 撤回了「平台可以预先查询哪些用户设备支持远程 attestation」的说法。也就是说，Helme 驳斥的论证里，有一部分原作者自己已经先收回了。
事实部分
「Passkeys 是陷阱」的四个核心论点，Helme 逐条给了核查结果，全部出自他 10 月 14 日的博文：
| 争议点 | 原文说法 | Helme 的核查 |
|---|---|---|
| 同步 passkey 的 attestation | 网站可以要求 attestation，逐步排斥特定用户 | 同步 passkey 被请求时返回 none；强制只会锁掉几乎全部用户 |
| AAGUID 的暴露范围 | 可用来识别并控制用户设备 | 只暴露厂商、型号加证书链，不含 OS、浏览器、固件或 root 状态 |
| YubiKey | 用它避开 OS 级 attestation | 每枚出厂自带 Yubico attestation 证书；enterprise attestation 本就是给企业强制锁定硬件设计的 |
| TOTP 与钓鱼 | TOTP 是给密码账户加安全的「好方案」 | Evilginx 类工具能实时中继 TOTP 和会话 cookie，他引用 Troy Hunt 的 Mailchimp 钓鱼事件作为实例；passkey 绑定域名，中继不了 |
Helme 把原文的建议概括为一笔亏本交易：拿一个防钓鱼的凭据，换一个可被钓鱼的凭据。他在文中写道：「故事很动听。只是它对不上这套东西实际运转的方式。」Mondello 的帖子补上了平台一侧的事实：attestation 对可同步的消费级凭据是设计上的反目标，写进了 passkey 设计者的非目标清单；银行等机构在 passkey 推广早期反复索要 attestation，被平台、浏览器和凭据管理应用顶了回去。
各方说法
Mondello 10 月 12 日在 Mastodon 上给出三点批评：把复杂的东西刻意描述成可疑的；把 TOTP 称作密码账户的「好方案」，而 web 上最常见的威胁是钓鱼，他说原文通篇没提这个词，TOTP 对此几乎没有防护力；在没有吃透主题的情况下连续做逻辑跳跃。这条帖子拿到 602 次转发、765 次收藏（截至 10 月 15 日查证时）。
Hacker News 上的反驳帖（截至 10 月 15 日查证时 421 分、588 条评论）正反交锋。反方的痛点在实现质量：用户 chaboud 说自己遇到过约三成网站把 passkey 流程做砸，他强调这是个人体感，不是统计；用户 dllu 描述在 Linux 的 Firefox 上登录 Okta，页面连「扫码用手机登录」的选项都不给，只能超时放弃。正方集中在模型本身：用户 WorldMaker 列出三大平台默认支持第三方密码管理器和迁移通道；dfabulich 补充说多数密码管理器不允许导出 passkey，改走应用对应用的凭据交换协议 CXP；用户 OkCompute64 自述几年里跨 Mac、iOS、Linux、Android 用 Bitwarden 存 passkey，没有出过问题。
编辑判断
这场辩论对两类人有用。做登录系统的团队可以核对的现状是：同步 passkey 的 attestation 就是 none，强制 attestation 等于放弃消费级登录，该投入的地方是多 passkey 支持、说得清楚的恢复流程和迁移通道。在意账户安全的普通用户该知道的是：高价值账户换 passkey 仍然比密码加 TOTP 更防钓，原文推荐的那套组合恰恰是可被实时中继的。凭证管理的基本常识也没有变，Shopify 给购物 Agent 定的条款就写明，别把 passkey 或验证码交给 Agent（见本站 Shopify 的 Any Agent 购物条款 一条）。
这场辩论没有解决的两件事，比 attestation 阴谋论更值得盯：一是跨设备登录的体验碎片化，HN 讨论串里排着一串翻车现场；二是同步密钥的导出与恢复之争，Bitwarden 允许导出，多数管理器不允许，各家取舍不同。至于「网站将来翻转 attestation 策略」的担忧，目前靠的是标准参与者的公开立场和平台的抵制，这是承诺，技术上没有屏障，值得继续观察。