Passkeys – 透视其内部机制

非驻留密钥 vs. 驻留密钥 / passkeys

• 非驻留 WebAuthn/U2F 密钥使用服务器存储的 handle，从单一秘密派生出每个站点的密钥对；令牌几乎保持无状态，可以支持“无限”站点，并且不会泄露其使用位置的任何信息。
• 驻留密钥（“可发现凭据” / passkeys）必须在认证器上为每个站点存储条目，以支持无需用户名登录，从而带来容量限制（几十到几百个槽位）以及潜在的隐私问题（认证器可以被查询某个域名是否存在某个账户）。
• 若干评论者认为，与强唯一密码 + 硬件 2FA 相比，passkeys 是一种退步，尤其是在网站放弃非驻留 WebAuthn 支持时更是如此。

安全性 vs. 可用性权衡

• 对于使用弱密码或重复密码的用户，passkeys 被视为重大升级（抗钓鱼、不会泄露密码）。
• 对于已经使用硬件密钥和密码管理器的安全意识较强用户，passkeys 可能降低灵活性或安全性（单因素、可同步、有限的证明）。
• 有人指出，你可以通过发送虚拟 handle 来使用非驻留密钥防止账户枚举，因此“必须先有密码”并不严格成立。

硬件令牌 vs. 同步 passkeys

• 硬件密钥：强隔离、证明、物理在场、PIN，非常适合受监管 / 高价值环境；但成本、密钥丢失风险、用户自行管理密钥，以及有限的驻留存储都是真实问题。
• 手机上的 passkeys / 安全区域配合云同步，被视为面向普通人群唯一可规模化的方案；大多数用户不会管理单独的令牌或备份。
• 有人担心，FIDO/WebAuthn 的工作越来越围绕平台 passkeys 进行优化，使漫游硬件认证器沦为二等公民。

生态碎片化与 UX

• 浏览器和操作系统支持并不一致（例如 Firefox mobile、Chrome flags、UA sniffing）；一些网站对 WebAuthn 处理不当、限制漫游密钥，或滥用 UX 流程。
• 密码管理器越来越多地支持 passkeys（桌面端和移动端），但集成和流程（例如提示、自动填充、回退到浏览器）仍然不够顺畅。
• 解释基本的“用你的脸 / 指纹登录”很容易；解释恢复、跨平台迁移，以及何时仍然需要密码，则被认为很困难且规范不足。

证明和控制

• 硬件令牌提供强证明；一些受监管行业依赖这一点。
• 主要平台的 passkey 实现已为同步凭据禁用或限制证明，这让这些用例感到沮丧。
• 另一些人则认为，缺少证明有利于用户自由，并反对类似 DRM 的控制，凸显了企业控制与用户自主之间的根本张力。