这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
恢复机制与安全实现
最容易被忽略的设计
MFA 越严格，一个现实问题越突出：用户丢了手机或验证器怎么办？
如果恢复流程很弱，攻击者就会专挑恢复入口打——因为这里往往是「安全后门」。所以设计原则是：恢复流程不能比 MFA 本身更弱。
恢复方式
| 方式 | 强度 | 说明 |
|---|---|---|
| 备用恢复码 | 中 | 开启 MFA 时发放一批一次性恢复码，用户妥善保存 |
| 已登录设备确认 | 中 | 用另一台已可信设备确认「确实是本人」 |
| 邮箱 / 手机二次验证 | 中 | 结合风控，验证绑定联系方式 |
| 人工审核 | 强 | 提交材料，人工审核，适用于高风险场景 |
恢复码的细节
如果采用备用恢复码：
- 一次性使用，用完即作废（或用掉大部分后提示重新生成）。
- 只显示一次，之后只能重新生成。
- 加密 / 哈希存储，数据库泄露也不能直接使用。
安全实现要点
MFA 验证本身要经得起攻击：
- 验证码短期有效，限制重试次数（防爆破）。
- TOTP 允许少量时间偏移（如 ±1 步），但不能过宽。
- 备用码只能用一次，并加密存储。
- 验证通过后给会话提升信任等级，但设置有效期，不是永久免验。
与会话联动
完成 MFA 后，系统记录：
session.assurance_level = high
mfa_verified_at = now接下来一段时间内，用户执行敏感操作不必重复验证。超过有效期或风险变化后，再要求重新验证。这是「验证强度跟随风险」的落地：把摩擦放在最需要的地方。
人工审核
极端情况（什么都丢了）走人工审核：
- 记录用户提交的材料。
- 记录审核人、审核结论、处理结果。
- 全程可审计——人工通道本身也是攻击入口。
上线检查清单
- MFA 因子是否至少组合两类？
- 是否提供多种因子供用户选择？
- 触发是否基于风险，而不是一刀切？
- 恢复流程是否不比 MFA 弱？
- 备用码是否一次性、加密存储？
- 通过 MFA 后是否给会话标记信任等级并设置有效期？
到这里，MFA 这块拼图也齐了。下一章我们把账号密码、Token、会话、SSO、OAuth、MFA 全部合并成一套完整的生产级身份认证架构。
发现内容有问题？
告诉我们哪里需要改进。