多因素认证与 Passkey
多因素认证（MFA）要求结合不同类型的身份证明。密码加另一个密码仍是同类因素；“无密码”也不自动代表满足某项多因素保证要求，需要看认证器如何保护私钥、是否执行用户验证，以及恢复流程。
OWASP MFA区分知识、持有、生物特征等因素，并讨论认证器更换与恢复风险。认证流程的强度也受最弱恢复入口限制。
认证方式的实际差别
| 方式 | 服务端验证什么 | 主要边界 |
|---|---|---|
| 短信或邮箱码 | 对消息通道的当前控制 | 通道失陷、转发、换卡与账号恢复 |
| TOTP | 对共享种子的控制 | 可被实时钓鱼，服务端需保护种子 |
| 推送确认 | 对已注册设备的控制与确认 | 疲劳轰炸、误确认与设备失陷 |
| WebAuthn / Passkey | 面向指定 RP 的私钥签名 | 认证器能力、用户验证、设备与同步恢复 |
| 一次性恢复码 | 对备用秘密的控制 | 保存位置与遗失后的处理 |
并非所有场景都需要强制同一种方式。管理员和高价值操作应采用更强策略，普通用户的登录成功率、无障碍和恢复成本也需要实际评估。
TOTP 注册与验证
RFC 6238使用时间步长驱动 HOTP，服务端和认证器根据共享种子计算短期验证码。常见时间步长为 30 秒；允许的时钟偏差窗口越大，同时可接受的验证码也越多。
注册建议采用“待确认 → 验证通过 → 启用”的状态：
- 用户完成近期认证，服务端生成随机种子，创建短期绑定请求。
- 通过受保护页面展示二维码，用户导入认证器。
- 用户输入一次有效码，服务端验证后才启用认证器。
- 提供恢复码，并记录安全事件与通知。
TOTP 种子不是普通密码哈希。服务端需要它来计算验证码，因此要加密保存、控制解密权限并规划密钥轮换；二维码、种子和 otpauth URI 不进入日志或分析系统。
验证时限制账号与挑战的尝试次数，原子记录已接受的时间步，拒绝同一 OTP 在有效窗口内再次成功。跨节点要共享重放状态；容忍时钟漂移不等于允许重复消费。种子重新绑定后，旧种子与旧恢复请求需要失效。
MFA 挑战不是完整登录态
密码正确、MFA 未完成时，只建立短期预认证上下文。该上下文绑定账号、已通过方式、挑战与时限，只能访问完成认证或取消流程所需的端点，不能访问普通业务 API。
挑战完成后轮换到正式 Session。否则攻击者拿到只验证了密码的 Cookie，就可能绕过第二因素直接调用 API。
同样，敏感操作的 step-up（提升认证强度）应有短有效期，并绑定到当前会话；高风险动作还可以绑定目标、金额或一次性操作请求。前端自己提交 mfa_passed=true 不产生可信认证事实。
WebAuthn 的注册与认证
W3C WebAuthn Level 2定义注册和认证验证流程。核心关系是：认证器保存私钥，RP 保存公钥与凭据 ID；认证器对含服务端挑战的结果签名，浏览器参与来源与 RP 范围约束。
服务端使用成熟库完成完整校验，至少明确以下边界：
| 阶段 | 需要约束的内容 |
|---|---|
| 发起注册 | 当前账号与近期认证、RP ID、允许算法、随机挑战 |
| 完成注册 | 挑战、操作类型、受信 origin、RP ID、用户在场及所需用户验证 |
| 发起认证 | 账号或可发现凭据策略、一次性挑战与时限 |
| 完成认证 | 凭据归属、签名、挑战、origin、RP ID 与标志位 |
challenge 需要一次性消费，并绑定发起流程；不能只检查“签名正确”。对允许 origin 使用精确配置，不能随意信任请求的 Host；RP ID 的选择会影响域名范围和未来迁移成本。
下面展示已登记凭据的认证过程。认证器完成本地交互，服务端负责验证结果并原子消费挑战，两者职责不同。
图中省略用户取消和设备不可用的分支：它们结束此次尝试，不生成成功认证结果。所需用户验证失败时也不能降级跳过；备用方式遵循已有账号策略。
Passkey 与用户验证
FIDO Alliance 的 Passkey 说明将其建立在 FIDO 公钥认证之上。Passkey 可以有设备绑定或可同步的形态，不能笼统承诺私钥永远不会离开当前设备。
用户可能通过本地 PIN 或生物识别解锁认证器。服务端通常收到签名及用户验证结果，不接收指纹或人脸模板。业务若要求用户验证，需要在请求中明确策略并在响应中校验结果；仅发生用户触碰不等于已完成同等强度验证。
WebAuthn 的 RP 绑定能抵御典型仿冒域名钓鱼，但不能消除本站 XSS、恶意扩展、已解锁设备失陷或账号恢复入口风险。是否满足特定认证保证等级，还要评估认证器与部署条件，不能只看“支持 Passkey”字样。
同步凭据的签名计数可能不具备严格单调特征。计数异常应结合认证器能力与风险策略处理，不适合一律永久封号。设备证明（attestation）也不是普通网站必选项；强制特定硬件会增加隐私、兼容性和供应链约束。
认证器管理与恢复
用户应能登记多个独立认证器，查看创建时间和最近使用情况，并撤销丢失设备。添加、删除或替换认证器要视作敏感操作，不能仅凭一个长期登录 Cookie 完成。
恢复码使用足够随机的独立秘密，只展示给用户并保存摘要，单次原子消费。重新生成一组后使旧组整体失效，避免遗漏的旧纸条继续具有账号控制权。
恢复流程需要明确：所有认证器丢失时接受什么证据、是否有等待期、如何通知已有渠道、恢复后撤销哪些会话。移除 MFA 后若仍保留攻击者已有会话，用户即使恢复成功也没有夺回全部控制权。
对必须强认证的账号，不应在认证器服务不可用时自动跳过 MFA。可以提供预先登记的备用方式或受审计的恢复流程，不能临时生成一个无审查的绕过接口。
参考资料
- OWASP：Multifactor Authentication Cheat Sheet
- IETF：RFC 6238 — TOTP
- W3C：WebAuthn Level 2 — Relying Party Operations
- FIDO Alliance：Passkeys