「Passkeys 不是陷阱」：远程证明是个纸老虎？
HN 热议三天后迎来反驳：安全工程师 Scott Helme 逐条拆解「passkey 是陷阱」论——同步型钥匙根本不报备、YubiKey 反而才是做证明的那个、TOTP 才是钓鱼的重灾区。访谈聊技术事实，也聊评论区「温水派」的长期主义质疑。
三天前那篇《Passkeys are a trap. Do not use them.》在 HN 掀起 700 多赞的风暴，本博客也做过一期解读。今天风暴有了回声：安全工程师 Scott Helme——写过开源 passkey 库、搞过 WhyNoPasskeys.com 的人——发了一篇逐条回怼的长文，标题就叫《Passkeys Are Not a Trap》，直接冲上 HN 首页，600 多条评论再战一轮。我请来老朋友顾深——独立安全顾问，给几个 WebAuthn 开源库做过安全审计的实战派。我们聊了聊这篇回怼站不站得住脚，以及评论区那帮「长期主义者」到底在怕什么。
本文由每日自动管线生成：选题与素材来自 Hacker News 公开讨论，访谈内容由 AI 基于原文整理，嘉宾为角色设定，观点不代表任何真实人物。
小听： 顾深，先帮大家对齐一下。三天前那篇「陷阱论」的核心子弹是什么？Scott Helme 这篇又是在打哪一颗？
顾深： 陷阱论的核心子弹就一颗，叫远程证明（attestation）：说 passkey 协议允许网站索要「你这把钥匙是哪台设备、哪套软件造的」的密码学证明，是个「隐藏旋钮」，网站迟早会把它拧满——只允许官方 App、官方系统、不能 root、不能分享账号。Helme 的回应也很集中：这颗子弹是纸糊的，理由分三层——你用的 passkey 根本不报备；就算报备，它报的也不是你想的那个东西；以及，那篇自己推荐的「解药」YubiKey，恰恰是报备最积极的那个。
小听： 第一层展开说说。「不报备」是什么意思？
顾深： 你我每天用的 passkey，绝大多数是同步型（synced）：iCloud 钥匙串、Google 密码管理、1Password、Bitwarden。这些钥匙在创建时，网站如果请求 attestation，拿回来的就是一个词：none。没有证明，没有型号，没有产地。Helme 自己写过开源 passkey 库，他敢拍胸脯说这个，是因为协议就是这么定的。而且消费级网站被建议「连问都别问」已经好几年了——一个网站明天宣布「只收带证明的 passkey」，等于瞬间把几乎全部用户锁在门外。哪个做 C 端的会干这种事？
小听： 可陷阱论的说法是，网站「可以问」，问本身就是权力。评论区有个高赞质疑：今天不拧，不代表明天不拧——技术从来都不是可选项。
顾深： 这是整个讨论里最有分量的长期主义质疑，Helme 的回应确实偏「现状派」。但先看第二层：attestation 到底报什么。陷阱论说它能证明「用了哪个官方 passkey 管理器、哪个操作系统、哪版固件」——这是错的。WebAuthn 的 attestation 只报一件事：认证器的品牌和型号，用一个叫 AAGUID 的标识符，附带厂商的证书链背书。它不知道你的操作系统、浏览器、装没装插件、手机越没越狱、固件版本，甚至不知道你手机什么颜色。把「型号申报」脑补成「全机体检」，是那篇文章最关键的一次偷换。
旋钮确实存在，但连着它的那根线，从来没接上过。
小听： 最讽刺的是 YubiKey 那段吧？陷阱论推荐大家用 YubiKey「躲开操作系统级的证明」，Helme 说这正好反了。
顾深： 对，这是全文最漂亮的一记回马枪。YubiKey 恰恰是「会做证明」的认证器本证：每把出厂都带着 Yubico 签发的 attestation 证书，企业级 attestation 的存在意义，就是让公司可以强制「只接受指定硬件钥匙」。Helme 自己也用 YubiKey，也推荐，但逻辑必须讲清楚——如果你怕的是 attestation，那篇的「解药」把你推向的正是 attestation 的大本营。这属于自己论据打自己脸。
小听： 再说 TOTP。陷阱论把 TOTP 捧成「本来就够好的方案」，Helme 说这是开倒车。
顾深： TOTP 比纯密码强，没人否认。但它有个致命伤：那 6 位数字是你亲手敲进网站的，敲错地方就没了。Evilginx 这类中间人钓鱼工具就是干这个的：实时把你敲的密码和验证码转交给真网站，顺手拿走你的 session。这不是理论，是今天账号被盗的主流手法。Passkey 解决的恰恰是这个问题：钥匙和域名绑定，你在 examp1e.com 上，浏览器根本不会掏出 example.com 的钥匙——没有数字可抄，没有「用户敲错」这个环节。拿一个抗钓鱼的凭证，换一个可被钓鱼的凭证，Helme 说这是笔亏本买卖，我同意。
没有数字可抄，钓鱼佬今晚要加班了。
小听： 评论区还有一派，我称之为「温水派」：当年安全带法也说只是次要执法理由，现在满大街「系好安全带否则罚款」。只要路修好了，车迟早会开上来。Helme 的「还没发生」是不是太天真了？
顾深： 这条质疑我认真对待了一半。历史确实站在温水派那边：Play Protect 从可选变强制、银行 App 的设备绑定，都有先例。但有两个硬约束是 Helme 没展开、却真实存在的：第一，苹果已经在标准流程里明确表态——消费级 passkey 不做 attestation，理由是隐私和体验（同步和备份对普通用户是刚需），还推了 uvi/uvm 这种「君子协定式」的折中扩展来堵合规的嘴；第二，iOS 根本不支持 attestation，任何想「只收证明」的大厂都得先放弃一半移动市场。所以「还没发生」不是天真，是有结构性原因的。但温水派的提醒也该收下：Helme 自己也说了——如果 attestation 真的爬进消费级登录，就该大声反对。反对的姿势要先摆好，别等。
小听： 还有一类声音我觉得更扎心：有人说真正的陷阱根本不是 attestation，是 usability 那一团乱麻——钥匙散落在 iCloud、Google、三星、Windows 四处，换平台就抓瞎，约三成网站的实现都是坑。
顾深： 完全同意，这是评论区里技术派和体验派难得的共识。协议是扎实的，落地是稀烂的：有的网站绑了 passkey 就不让你用别的方式登，有的只允许一把钥匙，有的跨设备流程要蓝牙结果公司电脑被锁死。还有人说的那种「平均用户」——iPhone 丢了，连 iCloud 账号密码都不记得，对他来说恢复链才是真正的陷阱。Helme 这篇是打假文，不是布道文，它没义务回答 UX 问题，但做产品的得听进去：passkey 今天的敌人不是阴谋论，是糟糕的实现和缺失的恢复故事。
小听： 收个尾。对中文开发者和普通用户，你的行动清单是什么？
顾深： 三条。第一，继续用 passkey，网站给了就注册，存在你信任的密码管理器里——1Password、Bitwarden 都支持同步和导出，别把鸡蛋全押在一家生态；第二，如果你在做登录功能，照 Helme 的建议：消费级场景别碰 attestation，连请求都别发；第三，把「反对姿势」准备好——标准、厂商、大厂的动向值得盯，但盯的是证据，不是预言。一句话：别为还没发生的证明，放弃已经到手的抗钓鱼。