为什么备用码是 MFA 的软肋
MFA 的可用性风险全部由备用码承担：它是设备丢失时唯一合法的自救路径，同时也是绕过第二因素的通道。保管不当就等于 MFA 失效，管得太严又会造成大量的登录阻塞。管理办法是三件事：一次性使用、离线加密保管、定期轮换，另外把设备丢失后的重置流程写成带审批的规程。
基本信息
| 加固项 | MFA 应急预案 |
|---|---|
| 适用平台 | 全部平台 |
| 常见载体 | TOTP 工具生成的备用码、厂商恢复码 |
| 保管要求 | 离线、加密、与设备分离存放 |
| 轮换策略 | 使用后立即作废并补发 |
| 风险等级 | 中 |
典型使用场景
- 新员工开通 MFA：同时交付备用码并登记保管位置
- 设备更换：用备用码登录后立即重置密钥与备用码
- 应急响应：怀疑备用码泄露时批量轮换
- 审计访谈：说明重置流程有强身份验证与双人审批
- 离职处理：回收硬件令牌并作废其备用码
密钥与备用码的核查
密钥与备用码的核查
# TOTP 的密钥与备用码通常在同一文件里，权限应为 600
ls -l ~/.google_authenticator
# 需要重置时重新生成：旧密钥与旧备用码同时作废，用户需重新绑定
google-authenticator
# 核查有多少账号仍在使用长期未轮换的配置
for f in /home/*/.google_authenticator; do [ -f "$f" ] && stat -c '%n %y' "$f"; done场景与正确做法
| 场景 | 正确做法 | 常见错误 |
|---|---|---|
| 新用户开通 | 备用码离线交付并登记保管位置 | 直接发到邮箱或聊天工具 |
| 设备丢失 | 强身份再验证加双人审批后重置 | 客服口头确认即重置 |
| 离职交接 | 回收令牌并作废备用码 | 只停用账号不处理令牌 |
| 定期维护 | 按周期轮换备用码 | 一套码长期使用 |
备用码与 TOTP 密钥往往存在于同一个文件里，文件泄露意味着第二因素整体失效，文件权限与备份介质都要一并管理。
备用码是一次性凭据，同一份列表在多处使用会破坏语义，轮换时要明确回收旧列表。
重置 MFA 的流程如果只靠客服口头确认，等于给自己开了一个绕过 MFA 的后门。