Passkeys 不是陷阱：解读无密码登录的真实争议

「Passkeys 是不是一个陷阱？」这个质疑在技术社区反复出现。一篇题为 Passkeys Are Not a Trap 的文章在 Hacker News 上引发讨论，核心观点很明确：把 Passkeys 等同于厂商锁定、数据收割或不可控的技术黑箱，是一种误读。

Passkeys 到底是什么

Passkeys 是基于 FIDO2 标准的无密码认证方案，用公私钥对替代传统密码。私钥保存在用户设备的可信执行环境或硬件安全模块中，服务器只存储公钥。登录时设备用私钥签名，服务端验签即可完成认证。

这套机制的直接影响是：不再有「密码」这个可被拖库、撞库、钓鱼的中间物。私钥不出设备，钓鱼站点拿不到可用于其他站点的凭证，因为签名与具体域名绑定。从安全模型上看，这比「密码 + 二次验证」的组合更收敛。

FIDO2 是 FIDO 联盟与 W3C 联合推动的认证标准组合，包含两个核心部分：WebAuthn（W3C 标准，定义浏览器与认证器之间的 API）和 CTAP2（Client to Authenticator Protocol，定义认证器与客户端设备之间的通信）。WebAuthn 已被主流浏览器普遍支持，使得网站可以通过统一接口调用设备上的认证器完成公钥签名验证，而无需自行实现底层协议。CTAP2 则负责让外接硬件密钥（如 YubiKey）或平台内置认证器与操作系统、浏览器协同工作。理解这两层分工，有助于区分「协议能力」与「产品体验」：WebAuthn 保证互操作性，CTAP2 保证硬件与平台的接入方式。Passkeys 正是在这套标准之上构建的用户友好封装，把原本需要外接密钥的流程内化为设备本地认证。

「陷阱论」的三个常见误区

误区一：Passkeys 等于被某家厂商绑定。

Passkeys 的争议大多来自同步机制。iCloud Keychain、Google Password Manager、Windows Hello 各自提供了跨设备同步，看起来像是把身份托付给了平台。但 FIDO2 规范本身并不要求同步——硬件安全密钥、本地平台认证器都是合规实现。同步只是可选的产品层能力，不是协议强制。

误区二：导出和迁移被锁死。

早期 Passkeys 确实缺少标准化的导出格式，这给了批评者口实。但相关规范工作一直在推进，跨平台迁移的通道正在被补齐。把「当前实现的限制」当成「协议的本质缺陷」，是这类讨论中常见的偷换。

误区三：Passkeys 是取代密码的唯一路径，拒绝即是落后。

Passkeys 是密码的补充而非强制替代。密码管理器、硬件密钥、甚至传统密码 + TOTP 仍会在相当长时间内共存。把一个可选方案说成「要么接受要么被淘汰」，本身就带有情绪化成分。

可信执行环境（TEE）与硬件安全模块（HSM）是 Passkeys 私钥安全的基础。TEE 是主处理器内部的一个隔离区域，操作系统和普通应用无法直接读取其中的数据，私钥的签名运算在该区域内完成，外部只能拿到签名结果。HSM 则是独立的专用安全芯片，常见于手机的安全元件、笔记本的 TPM 模块以及外接硬件密钥。两者共同的特点是：私钥在生成后不会以明文形式离开安全边界，即使设备被恶意软件感染或系统被攻破，攻击者也难以直接提取私钥。这解释了为什么 Passkeys 能有效抵御钓鱼——攻击者即便诱导用户访问仿冒站点，也无法获取绑定到真实域名的私钥。当然，TEE 和 HSM 并非绝对不可攻破，侧信道攻击、固件漏洞等仍是研究热点，但其攻击成本远高于传统的密码拖库。

真正的取舍在哪里

Passkeys 的代价不在于「陷阱」，而在于恢复模型的变化。密码可以写在纸上、记在脑子里、托付给他人；Passkeys 的私钥与设备绑定，一旦所有持有设备丢失，恢复路径依赖于平台账号和备份机制。这意味着账户安全的边界从「你知道什么」转移到了「你拥有什么 + 你能登录哪个平台账号」。

对普通用户来说，这是体验与安全的权衡；对高威胁模型用户（记者、活动人士、高风险企业）来说，硬件密钥加独立恢复方案仍然必要。讨论应该聚焦在这个层面，而不是笼统地给 Passkeys 贴上「陷阱」标签。

结论

Passkeys 不是陷阱，也不是万能药。它的争议本质上是「身份归属权」在无密码时代的重新分配——从服务端转向设备与平台。理解这一点，比站队支持或反对更有价值。批评实现缺陷是合理的，但把实现缺陷等同于协议阴谋，就偏离了技术讨论的轨道。