Passkey 把登录凭据换成一对绑定域名的密钥，私钥留在认证器里，服务器只存公钥，因此它天然免疫钓鱼和撞库。工程团队要判断的是两件事。attestation 会暴露多少客户端信息，以及凭据跟着平台账号走之后谁来负责找回。这两件事在规范里都有明确边界，也都有公开的实现限制。
attestation 能证明什么，不能证明什么
WebAuthn 的 attestation 只在注册环节出现，它携带认证器的 AAGUID 和一条厂商签到认证器的证书链，作用是把凭据来源绑定到某个型号。它不读操作系统版本，不检查浏览器扩展，也不判断手机是否 root。 多数用户手里的同步型 passkey 根本不返回 attestation，站点发请求收到的也是 none。这一点决定了很多担心的落点。面向普通消费者的站点宣布只接受带 attestation 的凭据，等于当场把绝大多数用户挡在门外。企业采购场景才需要它，用来强制指定型号的硬件密钥。
凭据绑定域名为什么挡住钓鱼
RP ID 是一个有效域名，默认取调用方的有效域。凭据只能用于注册时的同一个 RP ID，浏览器不会把 example.com 的凭据拿到 examp1e.com 上用。这个约束在内核层面生效，不依赖用户判断地址栏。
一次性验证码则仍会被诱导输入到假站点。反向代理式的钓鱼中间件把密码和验证码实时转给真站点，取走会话，这类攻击在现实中大量存在。
签名计数器为什么不能当安全信号用
规范里的 signCount 是 32 位整数，用途是让服务器发现凭据可能被复制，能力比很多人想的弱。
- 计数器为零表示认证器不实现该功能，不少平台认证器恒返回零。
- 计数器回退或停滞只提示可能存在克隆，不能证明这次登录来自克隆件。
- 同步型凭据在多台设备上使用时，各设备的计数增长本来就不连续。
把计数器异常直接当拦截条件会大面积误伤正常用户。合理做法是记录异常并提升验证等级。
平台同步把信任转移到哪里
同步型凭据由 iCloud 钥匙串、Google 密码管理器或第三方管理器持有，跨设备可用靠的是这些平台自己的账号体系。安全边界因此转移，攻击者不必攻破站点，攻破平台账号就等于拿到全部凭据。
工程上要接受两个后果。站点无法强制用户使用不同步的硬件凭据，只能提供选项。登录强度的上限不再由站点单独决定，平台账号的防护水平成为其中一环。
恢复流程才是真正难做的部分
设备丢了就是账号进不去，可用的恢复路径各有代价。
- 一次性恢复码。实现简单，用户很少妥善保存，泄露即等于失守。
- 邮箱或短信找回。覆盖面广，代价是把最易受攻击的通道请回来。
- 多凭据并存。安全性和可用性都好，需要注册流程主动引导用户加第二把。
- 客服人工审核。适合高价值账号，成本和社工风险都高。
任何一条路径都会在某个环节削弱抗钓鱼属性。团队要按账号价值和用户规模明确取舍，写进产品文档，而不是留给客服临场判断。
服务端实现要点
注册和断言校验要走完整流程，校验挑战的新鲜度、来源域、RP ID 和签名，不要为兼容跳过任何一项。用户句柄要稳定且不含个人信息。允许一个账号挂多个凭据，界面清楚展示每把凭据的添加时间和最后使用时间。保留备用登录方式，但压低它的权限层级，关键操作要求再用凭据确认。attestation 保持可选，只在明确的企业策略下强制。
常见问题
换手机后凭据还能用吗？ 同步型凭据跟着平台账号走，换机登录同一账号即可恢复。只存在单台设备上的凭据需要事先注册第二把，否则要走恢复流程。
计数器异常要拦截登录吗？ 不要。当作风控信号触发附加验证，直接拒绝会误伤正常用户。