证明可以传过去，私钥却不必进入表单，会怎样？
输入密码是在登录过程中提交共享秘密的知识。通行密钥采用另一种安排：服务保存公钥，验证器使用对应私钥回答挑战。私钥本身不会作为密码提交。理解这份分工，就能少一点神秘感；本文并不尝试搭建认证系统。
服务需要证明，而不是私钥的副本。
挑战针对的是这次访问
简化来看，服务提供新挑战，验证器在要求的用户交互和验证后生成签名响应，服务再用公钥检查响应及相关情境。新鲜度很重要：以前保存的一次响应，不应足以批准新的访问。
这只是角色解释，不是实现配方。真实 WebAuthn 包含结构化数据、依赖方标识、浏览器来源检查和策略判断，注册与账户恢复也需谨慎设计。我们没有生成密钥或凭据；图示把密码学操作留在标记边界内，没有用自制算法替代。
网站绑定改变了钓鱼问题
密码可以被输入一个只是看起来正确的表单。合适的通行密钥流程由浏览器和验证器把操作绑定到依赖方。仿冒站点不会因为展示相同标志，就拿到可用于真正站点的响应。这是“抗钓鱼”说法背后的重要区别。
抗钓鱼不等于账户周边的所有操作都安全。误导页面仍可要求付款、下载或不恰当权限，也可能针对恢复流程和较弱的备用入口。凭据改善的是登录中的特定环节，其他决策仍需要自己的依据和保护。
三个案例，分清两项要求
离线模型只有两项条件：预期网站一致，挑战仍为当前挑战。两者满足时接受；网站不同，即使挑战新鲜也拒绝；响应过旧，即使网站相同也拒绝。四项断言检查这个很小的判断表。
结果来自我们写下的规则，不是浏览器抵御攻击的实测。实验没有数字签名、验证器、账户或网络连接。表格帮助区分来源绑定和新鲜度，但任何一项都不足以构成完整验证器，更不能把示意图当成可部署的认证代码。
解锁设备与登录站点，是关联的步骤
面部、指纹或设备 PIN 可以在本地授权凭据操作。通常的 WebAuthn 安排中，站点收到的是与验证相关的信息，而不是生物特征图像副本。这不同于把指纹交给每家网站；实际行为仍取决于设备、验证器和服务策略。
通行密钥的可用位置也不同。有的通过提供方的凭据系统同步，有的绑定特定硬件。这会影响便利性和恢复。在替换旧登录方法前，应了解设备丢失时提供方如何处理，以及常用设备不可用时怎样进入账户。
启用时，也要安排备用路线
通过真实服务的账户设置，按支持的注册流程启用通行密钥。了解新方法之前，应保持现有恢复入口可用。涉及多台设备时，要确认哪些设备实际能够使用凭据，不能因为一台设置成功就假定全部准备好了。
还应检查旧的备用方法。强登录可能与较弱恢复路径同时存在，因此值得完整查看账户设置。目的不是多收集一个安全标签，而是让本人正常访问更顺畅，减少假网站索要可重复使用秘密的机会。