Passkey 如何消除密码 — WebAuthn 和 FIDO2 的工作原理

使用 Passkey 登录时，用户只需验证指纹、面部或设备 PIN，而无需输入冗长的密码。表面上看起来生物识别信息被发送到服务器，但实际结构并非如此。

Passkey 的核心在于为每个网站创建独立的公钥-私钥对，并让设备对服务器发送的一次性 Challenge 进行数字签名。服务器只存储公钥，而私钥和生物识别信息永远不会离开认证设备的受保护区域。

本文将首先梳理 Passkey、WebAuthn、FIDO2 和认证设备之间的关系，然后探讨注册和登录消息流、防钓鱼原理、同步 Passkey 以及恢复设计。

Passkey、WebAuthn 和 FIDO2 是同一个概念吗？

它们之间密切相关，但并非同一个术语。


术语	含义	负责范围

—	—	—
Passkey	用户替代密码使用的基于 FIDO 的登录凭证	同步型或特定设备绑定型公钥凭证
WebAuthn	Web 应用程序创建和使用公钥凭证的 W3C Web API	浏览器、RP 服务器和认证设备之间的注册和认证流程
CTAP	浏览器、操作系统等客户端与外部认证设备通信的 FIDO 协议	USB、NFC、BLE 安全密钥与平台之间的通信
FIDO2	结合 WebAuthn 和 CTAP 的公钥认证体系	涵盖 Web 和认证设备的标准集合

网站的 JavaScript 调用 navigator.credentials.create() 和 navigator.credentials.get()。浏览器与操作系统的 Passkey 存储或安全密钥等 Authenticator 进行通信，服务器则验证返回的签名。

웹 애플리케이션 ─ WebAuthn ─ 브라우저·운영체제 ─ CTAP ─ 외부 보안키
                                      └ 플랫폼 Authenticator

图：Passkey·WebAuthn·CTAP·FIDO2 的构成关系 · 基于 W3C WebAuthn Level 3 和 FIDO Alliance 资料重构

与密码认证有何不同？

在密码方式中，用户与服务器共享相同的秘密。即使服务器存储的是安全的哈希而不是明文，用户在登录时仍需向网站提交密码。如果输入到虚假网站，攻击者可以原样重用。

Passkey 使用非对称密钥。

사용자 기기: 개인키 보관 + Challenge 서명
서비스 서버: 공개키 보관 + 서명 검증

私钥是绑定到要登录网站的 RP ID 生成的。用户无需知道私钥的值，服务器也不会接收私钥。即使服务器数据库泄露导致公钥暴露，仅凭该公钥也无法创建新的签名。

生物识别信息的作用也容易被误解。面部或指纹数据并非向服务器证明身份的登录数据，而是设备内部私钥使用的本地用户验证手段。设备 PIN 也可以起到相同的作用。

1. Passkey 注册如何进行？

Passkey 注册是服务器将用户账户与新的公钥凭证关联起来的过程。

服务器创建注册选项和 Challenge

服务器生成具有足够熵的一次性 Challenge、RP 信息、用户标识符、允许的算法和用户验证要求等。

{
  "challenge": "server-random-bytes",
  "rp": {"id": "example.com", "name": "Example"},
  "user": {"id": "opaque-user-id", "name": "user@example.com"},
  "pubKeyCredParams": [{"type": "public-key", "alg": -7}],
  "authenticatorSelection": {"userVerification": "required"}
}

Challenge 必须在服务器信任的环境中随机生成，以防止重放攻击，并应与会话关联，临时保存直到注册完成。

浏览器请求认证设备生成密钥

Web 应用程序调用 navigator.credentials.create()。浏览器验证当前 Origin 与 RP ID 的关系，并向用户显示 Passkey 创建 UI。

用户通过生物识别或设备 PIN 批准后，Authenticator 会生成新的公钥-私钥对。私钥、RP ID 和用户句柄等凭证源由认证设备或安全的 Passkey 存储管理。

服务器验证注册响应并存储公钥

浏览器将 Credential ID、Attestation Object、Client Data 等发送到服务器。服务器至少验证以下内容：

返回的 Challenge 是否与颁发的值一致
origin 是否为允许的 HTTPS Origin
rpIdHash 是否与预期 RP ID 的哈希值一致
用户存在和用户验证标志是否满足策略
是否使用了请求的公钥算法
如果要求 Attestation，是否通过了信任策略

验证完成后，服务器存储 Credential ID、公钥、用户关联信息以及 Sign Count 和 Transport 等必要的元数据。私钥不存储。

图：WebAuthn 注册 Ceremony 的主要消息和验证项 · 基于 W3C WebAuthn Level 3 注册流程重构

2. Passkey 登录如何进行？

登录是服务器验证“用户是否确实拥有对该 Challenge 进行签名的私钥”的过程。

服务器发送认证 Challenge

服务器提供新的 Challenge、RP ID、允许的凭证列表和用户验证策略。使用可发现凭证（Discoverable Credential）时，即使用户不先输入 ID，浏览器也可以建议可用于该网站的 Passkey。

认证设备在用户批准后签名

当 Web 应用程序调用 navigator.credentials.get() 时，浏览器将当前 Origin 和 RP ID 传递给 Authenticator。用户通过指纹、面部或 PIN 批准后，Authenticator 会使用私钥对以下信息进行签名：

authenticatorData || hash(clientDataJSON)

这包括 RP ID 的哈希、用户存在和验证标志、签名计数器以及与服务器 Challenge 和 Origin 相关联的数据。

服务器使用公钥验证 Assertion

服务器查找注册时存储的公钥并验证数字签名。只有在确认 Challenge、Origin、RP ID Hash、UP·UV 标志、Credential ID、签名算法和策略后，才会颁发会话。

서명 유효 + Challenge 일치 + Origin 허용 + RP ID 일치 + 정책 충족
→ 로그인 성공

图：WebAuthn 认证 Ceremony 和 Assertion 验证流程 · 基于 W3C WebAuthn Level 3 认证流程重构

Passkey 为什么能有效抵御钓鱼攻击

Passkey 的私钥绑定到特定的 RP ID。即使攻击者试图在他们的 examp1e.com 上使用在 example.com 上创建的凭证，浏览器和 Authenticator 也会将其判断为不同的 RP ID，因此不会提供或使用该私钥进行签名。

虽然密码管理器可能会让用户忽略警告并复制密码，但 WebAuthn 私钥并非 Web 脚本可以读取和复制的值。W3C 规范设计为脚本无法直接访问凭证本身，只能接收 Credential 对象形式的结果。

服务器也必须验证返回的 origin。如果 RP ID 范围限制是第一道防线，那么 Origin 验证是减少错误实现和跨源风险的额外一层。

然而，Passkey 并不能阻止所有攻击：

已认证的会话 Cookie 被窃取的攻击
用户设备或浏览器本身被入侵的情况
Passkey 注册前账户恢复流程被劫持的情况
恶意 OAuth 授权或远程控制诈骗
服务器错误实现 Challenge、Origin、RP ID 验证的情况

Passkey 是一项显著减少登录钓鱼和凭证填充的技术，但它并非替代整体账户安全的万能工具。

同步 Passkey 与设备绑定 Passkey

FIDO 联盟将 Passkey 分为可在多个设备上安全同步的形式和绑定到特定设备的 Device-bound 形式。


区分	同步 Passkey	设备绑定 Passkey

—	—	—
可用性	在同一平台账户的多个设备上使用	需要已注册的设备或安全密钥
恢复	利用平台账户的恢复机制	需要备用安全密钥或其他注册凭证
主要风险	云账户被盗和依赖恢复策略	设备丢失时可能失去账户访问权限
适用环境	普通消费者服务	管理员、高风险业务、受监管环境

同步并不意味着将私钥以明文形式上传到云端。平台提供商会应用端到端加密和设备/账户保护，但具体的保护和恢复方式因生态系统而异。组织应根据风险级别决定是否同步、Attestation 和设备管理要求。

通过手机登录其他 PC 的混合流程

即使在没有 Passkey 的公共 PC 上，也可以使用手机的 Passkey。这涉及用手机扫描浏览器上显示的二维码，确认近距离，然后通过手机的生物识别进行批准。

重要的是，Passkey 私钥不会复制到 PC 上，而是手机充当认证设备来签署该登录 Ceremony。由于公共 PC 上可能会留下最终的服务会话，因此仍然需要注销和会话管理。

服务器实现中必须验证的项目

WebAuthn 并非仅通过调用浏览器 API 就能完成。服务器验证是安全的核心。

Challenge 应在服务器端充分随机生成，并作为一次性、短时效的凭证进行管理。
验证返回的 Challenge 是否与会话中存储的值完全一致。
origin 应与允许列表精确比较，不应允许意外的子域名。
验证 rpIdHash 是否与设定的 RP ID 的 SHA-256 值一致。
确认 UP (User Present) 和 UV (User Verified) 标志是否满足服务策略。
验证 Credential ID 与用户账户的关联。
使用已注册的公钥和算法验证 Assertion Signature。
Sign Count 可用作怀疑克隆的信号，但需考虑同步凭证的特性。
将注册、删除、恢复、添加新设备等生命周期事件记录到审计日志中。

与其直接实现密码处理，不如使用经过验证的服务器库，但操作员必须理解该库验证了哪些值和策略。

引入 Passkey 时，账户恢复变得更加重要

如果只加强登录，而账户恢复仅通过一个电子邮件链接完成，攻击者就会选择较弱的路径。

推荐的设计如下：

允许一个账户注册多个 Passkey
用户可以查看和删除 Passkey 列表及最后使用的设备
新 Passkey 注册和恢复时进行强认证
管理员账户应保管备用硬件安全密钥
安全颁发恢复代码并审计重新颁发情况
对可疑的注册、删除事件进行通知
告知在密码并行期间，现有钓鱼风险仍然存在

如果 Passkey 仅作为附加认证手段提供，虽然转换容易，但密码攻击面依然存在。服务应观察用户转换率和恢复成功率，逐步扩大无密码（Passwordless）政策。

结论

Passkey 并非将生物识别信息发送到服务器的技术，而是通过使用针对每个网站的公钥加密来消除密码这一共享秘密的技术。

注册时，认证设备创建密钥对，服务器只存储公钥。登录时，服务器发送一次性 Challenge，用户设备在本地验证后使用私钥签名，服务器再用公钥验证。由于凭证绑定到 RP ID 和 Origin，因此虚假网站很难获取相同私钥的签名。

Passkey 的安全性不仅通过强大的加密技术实现，还需要浏览器源验证、认证设备的用户批准、服务器准确的 Ceremony 验证和安全的账户恢复协同工作才能完成。

用户无需记住密码，服务可以显著降低密码数据库泄露、钓鱼和重用攻击的风险。在设计下一个认证体系时，现在是时候考虑以 Passkey 为中心的公钥认证作为默认路径，而不是仅仅修补密码。