Passkeys 完全指南：为什么服务器再也存不了你的密码副本

密码模型的原罪：服务器必须持有「能验证你的东西」

密码的根本缺陷不是弱口令——是模型。为了让服务器能验证你，它必须持有一个「你的秘密的等价物」（哪怕是哈希）。于是数据库一泄露，十亿级凭证瞬间进入撞库字典；钓鱼页面一搭好，你亲手把秘密递给攻击者。密码生成器和强度检查解决的只是「秘密可不可以被猜」的问题，「秘密可不可以被偷」从没解决过。

Passkey 换掉了整个模型：服务器不再持有任何版本的你的秘密。

工作原理：注册与登录各一次非对称签名

Passkey 建立在两份标准上：W3C 的 WebAuthn（浏览器 API）和 FIDO 联盟的 CTAP2（设备通信协议）。流程只有两段：

注册（一次）

1. 设备在安全芯片（TPM / Secure Enclave）里生成一对非对称密钥
2. 私钥永远不出芯片；公钥 + 一个凭据 ID 发给网站存档

登录（每次）

1. 服务器发一个随机挑战值
2. 浏览器确认域名无误后，设备要求用户验证（指纹 / 面容 / PIN）
3. 设备用私钥对「挑战值 + 域名哈希」签名，返回签名
4. 服务器用注册时的公钥验签

没有共享秘密的传输、没有可重放的凭证——拿到签名无法伪造下一次，拿到数据库也无法生成登录能力。

抗钓鱼是结构性的，不是概率性的

TOTP 验证码也能被钓鱼页面实时转发（中间人当场问你「6 位数字」）。Passkey 做不到这一点的原因在密码学结构里：签名内容包含目标域名的哈希（rpIdHash）。你在 github.com 注册的 passkey，在 githsb.com 的钓鱼页上调用时，浏览器发现域名不匹配，直接拒绝出签名——不是「攻击者很难」，是「签名在数学上就不存在」。

三种认证方式的能力对照

最后一行是 passkey 与后量子迁移的交集：passkey 的非对称地基同样要面对算法轮换，好在 WebAuthn 的算法列表是可扩展的——这是 crypto-agility 的一个教科书案例。

同步 passkey 与设备绑定 passkey

• 同步 passkey：私钥经平台钥匙串（iCloud / Google 密码管理器）在设备间端到端加密同步——换手机不丢钥匙，代价是信任平台账户
• 设备绑定 passkey：私钥锁死在单个安全密钥/设备里，不同步——银行和高安全场景的选择，代价是丢设备 = 丢凭据

企业落地的三大难题

2026 年 passkey 用户已过十亿、认证量同比翻倍，但企业侧的摩擦不在「能不能用」而在运营（KuppingerCole 2026 报告点名的三件事）：

1. 注册：存量账户如何引导补登 passkey（机会窗口：密码重置时）
2. 多设备：跨生态（Android ↔ iPhone）的同步断层仍要靠扫码/蓝牙桥接
3. 恢复：账户恢复流程若降级回短信/邮件，整条链的最弱环就在那里——恢复通道必须与主认证同强度

实现注记 / Implementer's note

写站内 TOTP 工具时我对「共享秘密」四个字格外敏感：TOTP 的安全性依赖服务器与客户端持同一份种子，时间窗和 30 秒轮换只是给它上了迟滞的锁；passkey 把这份共享性彻底拆掉，代价是把信任搬进了硬件。另一个体会是强度评价体系的崩塌：密码强度可以谈熵、谈字典攻击，passkey 根本不存在「可猜测空间」这个维度——非对称签名的安全度量是算法与密钥长度，跟用户选了什么毫无关系。这也是为什么密码时代的 NIST 指南在 passkey 语境下整体转向了「认证器保证级别」这类硬件侧指标。

相关阅读

• 密码生成器使用指南（2FA 强度阶梯的上一章）
• TOTP 动态口令指南
• 后量子迁移自查清单（passkey 的算法层演进）
• JWT 与 Session 的取舍（认证之后的事：会话怎么管）