题干与适用场景
这道题考察前端工程师能否把 WebAuthn 扩展接入真实的端到端加密流程。PRF 可以为凭据提供与输入绑定的伪随机输出，适合在客户端派生加密密钥；它不等于登录签名，也不自动解决多设备、备份、删除或浏览器兼容。回答需要同时覆盖浏览器 API、密码学边界、用户体验和恢复风险。
面试官考察什么
- 是否理解 passkey 的认证用途与 PRF 密钥材料用途不同。
- 是否把扩展支持、用户验证、盐值、密钥派生和服务器存储分开设计。
- 是否能处理新增设备、凭据删除、同步与不可恢复的用户风险。
- 是否明确降级、错误反馈和不把密钥材料发送到服务器的边界。
回答前需要澄清的问题
先确认威胁模型：服务器是否被视为不可信，客户端脚本供应链是否在范围内，是否需要跨设备同步？数据是整库加密还是字段加密，用户能否接受丢失凭据后无法恢复？目标浏览器和 WebView 是否受控，是否允许用户注册多个 passkey？服务器需要保存哪些密文、盐值、凭据 ID 和版本信息？
30 秒回答框架
我会把 PRF 当作客户端密钥材料来源，而不是把登录断言当作加密密钥。注册时创建或选择支持 PRF 的凭据，为每个用途生成不可预测的盐值；解锁时通过带 PRF 输入的认证操作取得输出，在浏览器内用标准 KDF 派生包装密钥，再解包数据密钥。服务器只保存凭据公钥、盐值、密文和版本，不接收 PRF 输出。先检测扩展结果和用户验证，准备多凭据恢复或明确不可恢复提示；不支持时不静默声称端到端加密，可选择普通加密或阻止启用。记录失败、恢复和兼容性指标后逐步扩大范围。
分步骤深入解答
1. 区分认证与加密密钥
WebAuthn 登录返回的是对挑战的签名，用来证明凭据持有者；PRF 扩展则根据输入产生与凭据关联的伪随机输出。不能把签名、凭据 ID 或客户端扩展 JSON 直接当作 AES 密钥。加密方案应有独立的数据密钥和明确的派生、包装关系。
2. 设计注册与盐值
注册时请求 PRF 扩展并让用户完成用户验证；为每个加密域或密钥版本生成随机盐值，并把盐值与凭据 ID、算法版本一起作为公开元数据保存。盐值不是秘密，必须保证用途隔离，换用途或轮换密钥时使用新盐值。注册结果要检查客户端扩展输出，不能仅依据请求参数推断支持。
3. 设计解锁与派生
解锁时先从服务器取得盐值和密文元数据，再发起带 PRF 输入的认证操作。浏览器返回扩展结果后，在客户端验证结构和长度，再使用标准 KDF 派生包装密钥，解包随机生成的数据密钥，最后解密内容。PRF 输出和中间密钥只在需要的内存范围内存在，日志和遥测不得记录它们。
4. 处理能力检测与兼容性
使用公开的能力检测和 getClientExtensionResults() 判断实际结果，并区分“不支持扩展”“用户取消”“凭据没有 PRF 初始化”和网络失败。W3C 的实现状态仍需按目标浏览器、操作系统和 WebView 验证；不能把单一浏览器的成功当成全平台保证。把兼容性矩阵和最小支持版本写入发布策略。
5. 设计多设备与恢复
每个设备可注册独立凭据，并为同一数据密钥保存各自的加密包装版本。新增设备需要已解锁设备、恢复密钥或受控邀请来重新包装数据密钥；不能让服务器仅凭登录态解密。用户删除所有凭据且没有恢复材料时，必须明确数据不可恢复，并在启用前让用户确认。
6. 规划降级与迁移
不支持 PRF 时可以保持服务器可读的普通加密方案、引导用户换用支持的浏览器，或阻止启用端到端模式，取决于威胁模型。降级必须显式标记，不能把不同安全等级混在同一 UI。算法、盐值和密文格式都要带版本，便于未来迁移和撤销旧凭据。
高质量示范回答
我会把 WebAuthn PRF 视为客户端密钥材料来源，不把登录签名或凭据 ID 当作加密密钥。注册时请求 PRF、完成用户验证，为每个加密域生成随机盐值，并保存凭据 ID、盐值和算法版本；解锁时取得这些元数据，发起带 PRF 输入的认证，在客户端用标准 KDF 派生包装密钥，解包随机生成的数据密钥，再解密内容。服务器只保存公钥、密文和公开元数据，PRF 输出、中间密钥与明文不离开客户端。实际读取 getClientExtensionResults() 区分扩展不支持、未初始化、取消和网络错误。每台设备注册独立凭据并分别包装数据密钥，新增设备需要已解锁设备或恢复材料；所有凭据丢失时明确不可恢复。PRF 不可用则显式降级或阻止启用，并按浏览器矩阵、失败率和恢复成功率逐步扩大。
常见错误
- 把 WebAuthn 登录签名、凭据 ID 或客户端扩展 JSON 直接当作对称密钥。
- 只检查请求是否带有 PRF 参数，不检查实际扩展输出和初始化状态。
- 把盐值当秘密，或在多个用途之间复用同一盐值。
- 让服务器接收 PRF 输出，或在日志、错误追踪和分析中记录密钥材料。
- 只设计单设备成功路径，没有新增设备、删除凭据和恢复方案。
- PRF 不可用时静默切换到较弱方案，仍显示端到端加密。
追问及应对
PRF 输出可以直接作为 AES-GCM 密钥吗？
应先按方案使用标准 KDF 和用途域分离，再得到固定长度的包装密钥；不要把协议输出直接暴露给多个加密用途。数据密钥应随机生成并被包装，而不是由用户凭据决定全部密文密钥。
如果用户在另一台设备上登录，服务器能帮他解锁吗？
服务器只能提供盐值、密文和凭据元数据，不能凭登录态还原 PRF 输出。需要已解锁设备、恢复密钥或用户明确配置的密钥共享流程来包装新设备的密钥。
如何判断浏览器真的支持 PRF？
请求时声明扩展后，读取认证结果的客户端扩展输出并检查预期字段、长度和错误状态；同时维护目标浏览器、操作系统和 WebView 的实测矩阵。能力检测 API 只能说明可请求，不能替代真实认证验证。
服务器端脚本被注入时，端到端加密还安全吗？
PRF 不能解决活跃前端脚本被篡改的问题。还需要内容安全策略、依赖和发布完整性、敏感操作隔离与审计；面试中应明确“服务器看不到历史密文”与“客户端运行环境可信”是不同假设。