近日,名为 Passkeys are a trap. Do not use them. 的帖子在黑客新闻(Hacker News)上排名很高,多次被问是否属实。它面向非技术用户,主张停用通行密钥(Passkeys),回到 TOTP 码和密码。该帖称通行密钥支持证明(attestation)机制,网站可要求提供密码学证明;作者称这是隐藏的旋钮,网站会慢慢收紧,只允许用户用受认可软件登录。结合 uBlock Origin、FIDO 联盟(FIDO Alliance)和英国(UK)的图像扫描提案,该帖结论称:通行密钥并非为优先考虑用户利益而设计。
正文
最近几天,一篇名为 Passkeys are a trap. Do not use them. 的帖子流传甚广,在 Hacker News 上排名很高,也有人多次把它发给我,问我“这是真的吗?”。这篇文章面向“非技术网民”,核心建议是别再用 Passkeys,退回到 TOTP 码加密码。
论点
这篇文章看似只提出一个核心论断:Passkeys 支持一种叫“证明”(attestation)的机制,网站可以要求加密证据,证明通行密钥是由什么生成的。
作者把它称为“隐藏的旋钮”,认为网站会慢慢把旋钮调高,最后你只能用获得批准的软件、在获得批准的操作系统上登录,不能修改系统、不能用 LineageOS,也不能共享 Netflix 密码。再扯上 uBlock Origin、FIDO Alliance 的成员名单和英国的图像扫描提案,结论就成了 Passkeys“并非为优先考虑你的利益而设计”。
这是个很有说服力的故事。但它和这些技术的真实运作方式根本对不上……

你的 Passkeys 不会提供证明
大多数人使用的 Passkeys 是同步 Passkeys,存放在 iCloud Keychain、Google Password Manager、1Password、Bitwarden 或你选择的任何其他软件里。这些 Passkeys 根本不会向网站提供证明声明;网站虽然可以要求,但返回的其实是 none。我之所以知道这一点,是因为我写了一个开源 Passkeys 库并提供给了所有人。
如果一家消费级网站明天决定只接受带证明的 Passkeys,它会立刻把自己几乎所有用户挡在门外。哪家网站会这么干?更何况,面向消费级网站的指导多年来一直都是连证明都不要去请求。
证明并不是你以为的那样
那篇文章把证明描述成可以证明“正在使用获得批准的 Passkey 管理器、操作系统和固件”,这根本不对。
当证明存在时,WebAuthn 证明只会告诉网站认证器的品牌和型号,也就是由厂商证书链背书的 AAGUID。它不会透露你的操作系统、浏览器、扩展、手机是否 root 或越狱、固件版本,甚至连颜色都不会说。
YubiKey 的建议
这是最让我意外的部分。对于想要更强安全性的人,那篇文章推荐使用 YubiKey 之类的硬件安全密钥,理由是它“避免了操作系统级别的证明”。
但 YubiKey 恰恰是会做证明的认证器。每一个 YubiKey 出厂时都带有 Yubico 签发的证明证书,而企业证明机制的存在,正是为了让组织能够要求使用获得批准的硬件密钥。我仍然会向任何想要的人推荐 YubiKey,它们很棒,我自己也在用;但如果证明正是你担心的事情,那篇文章自己的建议反而把你推向了证明,而不是让你远离它!
TOTP 是倒退
那篇文章把 TOTP 捧为“已经”很好的解决方案。TOTP 当然比单用密码更好,但它有个大弱点:你可能把验证码输进错误的网站——问问我的好朋友 Troy Hunt 就知道了。像 Evilginx 这样的钓鱼工具会坐在中间,把你的密码和验证码实时转发到真实网站,然后拿着你的会话离开。这不是理论推测,今天大量的账户被盗就是这样发生的,而且我们有证据。
这正是 Passkeys 要解决的问题。Passkey 与它被创建的域名绑定,因此你的浏览器绝不会把 example.com 的 Passkey 用在 examp1e.com 上。没有验证码可读,用户也不会犯错。作者在附录里甚至承认了这一点,说 Passkeys 与域名绑定,能抵御中间人攻击,但仍然让读者别用它们。把一种抗钓鱼的凭证换成可被钓鱼的凭证,是非常糟糕的买卖……
你该怎么做
继续用 Passkeys!只要网站提供,就启用它,并存放在你信任的密码/Passkey 管理器里。如果你希望凭证能在不同服务间转移,就选支持这一点的提供商。如果你担心证明会逐渐渗入消费级登录,那确实值得大声反对(如果真有那一天)。但这件事并没有发生,最大的那些提供商并不支持它;今天因为等待而拒绝 Passkeys,并不会保护你免受任何伤害,只会让你暴露在钓鱼攻击之下。
最重要的是,我想说:我在所有能用 Passkeys 的地方都在用,因为它们是当前我们保护账户的最佳选择。而它们并不是陷阱。
评论
多数人对这篇反驳「Passkeys 是陷阱」的文章并不买账,分歧主轴不是 Passkeys 现在是否要求 attestation,而是厂商能否借 attestation、封闭生态和导出限制在未来逐步收回控制权;少数人支持文章,认为 Passkeys 在 iOS/macOS 等环境下体验和安全都更好,所谓陷阱论是夸大或为反对而反对。
认为文章用“现在未强制 attestation”回避了中心化控制与锁定风险
- 目前多数密码管理器让 attestation 返回空,但标准预留了认证能力:站点可对老用户保留不认证、却要求新用户使用认证 Passkey,或先诱导进入封闭生态,再把不认证变成默认关闭、埋在深处的“高级选项”;只支持特定认证器、而这些认证器又只兼容特定 OS 或浏览器,也能间接达到限制效果。银行强制 Play Protect、Google 强制 OAuth2、企业 IT 已开始强制硬件 attestation,都说明控制权可以逐步转到平台手里。导出方面,Bitwarden 能导出明文 JSON,1Password 仅限手机端特定协议导出,iCloud/Google 等更可能只允许应用间转移,锁定其实已经开始。(高赞)
- 需要引用时,只用一句中文意译: > 先把用户圈进封闭的 Passkey 生态,再慢慢给不认证加摩擦,这部电影我们早就看过了。(@xoa)
认为 Passkeys 的 UX、跨设备与恢复机制是灾难,普通用户会被设备或账户锁死
- 提示混乱,用户不知道 Passkey 会存进 Google、Samsung、iCloud 还是 Windows,也不知道换平台或设备间能否同步;在工作机无蓝牙、设备丢失或找不到当年创建的 iCloud 账户时就会无法登录,硬件 Passkey 又难以像 TOTP 那样备份,很多人觉得 TOTP 扫二维码反而更省事,Passkeys 则是把人绑死在设备和生态上。(较多人)
- 需要引用时,只用一句中文意译: > 陷阱就是普通用户丢了 iPhone,却连三年前买手机时创建的 iCloud 登录是什么都不知道。(@sdcfgy)
认为所谓“陷阱”文章夸大其词,Passkeys 在体验和安全上更好
- 支持者认为 Passkeys 的问题主要是 UX 且正在改进;在 iOS/macOS 上用指纹登录体验更好、更能防钓鱼,浏览器和操作系统的远程连接也让在工作电脑登录个人账号变得简单,因此反 Passkey 的声音只是为反对而反对。(少数人)
- 需要引用时,只用一句中文意译: > 反 Passkey 的人只是单纯为了反对而反对。(@mixdup)
认为硬件与生物识别绑定带来独特风险,不如密码配合独立 2FA
- 手机上的生物识别可被政府强制用于解锁设备,法律上不同于 PIN 或密码;任何绑硬件的方案一次丢失或损坏就可能永久锁死,除非采用更复杂的多把钥匙方案,硬件 Passkey 还不能像 Aegis 里的 TOTP 那样备份。有人因此继续用纸笔记录的密码加多种 2FA,并把硬件密钥与手机分开。(少数人)
- 需要引用时,只用一句中文意译: > 在美国相关法律改变前,我会继续用密码和独立于手机的硬件密钥,因为政府可以强制你用生物识别解锁设备,却不能这样强制密码或 PIN。(@verdverm)
认为现有密码管理器已足够,Passkeys 没带来相称收益
- 有人已用密码管理器生成随机密码并自动填充,配合检查网址就能防钓鱼且易于共享;Passkeys 提示让人不知道存到哪、是否同步,也没有解决对托管方可能泄密的担忧,因此没有足够理由从随机密码切换过去。(少数人)
- 需要引用时,只用一句中文意译: > 提示总是很混乱,我不知道它会存到浏览器、操作系统,还是这些设备之间会不会同步,密码管理器自动填充随机密码已经够用了。(@hbn)
有价值的补充
- attestation 细节:WebAuthn attestation 只通过 AAGUID 和厂商证书链说明认证器型号,并不直接上报 OS、浏览器、是否 root 或固件版本;但网站可以只接受某些认证器,而这些认证器又只支持特定系统或浏览器,从而间接实现同样的限制。(@Vexs、@goda90)
- 企业现实:企业环境里 IT 部门已经在到处强制硬件 attestation,证明认证要求不再由用户自己掌控,而是交给中心化平台。(@lelandbatey)
- 导出冷知识:Bitwarden 支持把 Passkey 导出为普通 JSON,1Password 只能通过特定协议导出且必须在手机 App 操作,iCloud/Google/1Password 等大多无法导入 KeePass,封闭生态的锁定已经开始。(@embeng4096、@xoa)
- 代表社区情绪的玩笑:有评论用“眼下锅还是凉的,就无视下面的火直接跳进去”嘲讽“现在还没强制 attestation 所以不用担心”的说法。(@mik1998)