一、什么是 2FA / MFA？为什么说是“质变级提升”
普通登录只有一个因子：
你知道什么 —— 密码
2FA 增加一层独立因子：
你拥有什么 / 你是什么
常见组合：
- 密码 + 短信验证码
- 密码 + 邮箱验证码
- 密码 + Google Authenticator
- 密码 + 指纹 / FaceID / 硬件令牌
攻击场景对比：
| 场景 | 无 2FA | 有 2FA |
|---|---|---|
| 数据库泄露 | 直接沦陷 | 攻击失败 |
| 撞库攻击 | 大量账号被攻破 | 仍无法登录 |
| 钓鱼攻击 | 成功登录 | 动态码阻断 |
| 内部人员泄露 | 极高风险 | 有效拦截 |
所以说： 2FA 几乎是登录安全从“防君子”到“防黑产”的分水岭。
二、2FA 常见三种实现方式及优劣
1. 短信验证码（SMS OTP）
流程
- 输入用户名 + 密码
- 系统判断需要 2FA
- 发送 6 位验证码到手机号
- 用户输入验证码
- 验证通过 → 登录成功
优点
- 成本低
- 实现简单
- 用户接受度高
缺点
- SIM 卡劫持风险
- 被中间人/运营商攻击
- 成本随量增加
- 可被短信轰炸攻击
适用场景
- ToC 系统
- 普通用户
- 中低安全场景
2. 邮箱验证码（Email OTP）
特点
- 比短信安全
- 成本更低
- 延迟可能略高
常用于：
- 后台管理系统
- 内部系统
- 风险判断临时验证
3. Google Authenticator（TOTP 动态口令）
这是企业级最推荐形态。
工作原理：
- 用户在绑定时生成一个 secret
- 手机 App 每30秒生成一个 6 位动态码
- 服务端按相同算法验证
常见 App：
- Google Authenticator
- Microsoft Authenticator
- Authy
特点：
| 维度 | 表现 |
|---|---|
| 安全性 | ✅ 极高 |
| 网络依赖 | ❌ 不依赖网络 |
| 被劫持可能 | 极低 |
| 用户体验 | 中等 |
| 实现复杂度 | 中等 |
推荐用途：
- 管理员
- 运维账号
- 金融账户
- 高权限系统
三、典型登录流程设计（含 2FA）
标准推荐流程如下：
1. 用户输入账号 + 密码
2. 后端验证密码
3. 判断是否开启 2FA
├─ 否 → 登录成功
└─ 是 → 进入二次验证阶段
4. 二次验证
├─ 发送短信 / 邮件
└─ 或输入 Authenticator 动态码
5. 验证通过 → 登录成功
6. 创建 Session / Token
注意： 2FA 必须在密码验证通过后，而不是之前。
四、架构设计视角（Passport 平台）
数据模型建议
user_security (
user_id bigint,
mfa_enabled boolean,
mfa_type varchar, -- SMS / EMAIL / TOTP
mfa_secret varchar, -- 仅 TOTP 使用（加密存储）
phone varchar,
email varchar,
last_mfa_time timestamp
)
登录态状态机设计（推荐）
新增中间态：
- PASSWORD_VERIFIED
- MFA_REQUIRED
- LOGIN_SUCCESS
完整流程示意：
[INIT]
↓ 输入账号密码
[PASSWORD_VERIFIED]
↓ 判断是否开启 2FA
[MFA_REQUIRED]
↓ 输入二次验证码
[LOGIN_SUCCESS]
五、推荐策略：从 MVP 到企业级
MVP 级别
✅ 管理员强制 2FA ✅ 普通用户可选开启 ✅ 支持短信 or 邮箱 ✅ 登录敏感操作二次验证
企业级
✅ 默认所有后台账号开启 TOTP ✅ 强制高权限用户绑定 Authenticator ✅ 强制首次登录完成 MFA 绑定 ✅ 风险登录触发动态 MFA ✅ 定期审计 MFA 启用情况 ✅ 登录策略引擎控制
六、如何优雅地“只对高权限账号开启”
推荐策略：
| 用户类型 | 是否强制 2FA |
|---|---|
| 超级管理员 | ✅ 必须 |
| 运维人员 | ✅ 必须 |
| 普通管理员 | ✅ 推荐 |
| 普通用户 | 可选 |
可配置规则：
if role in [ADMIN, OPS, FINANCE]
require MFA
高价值操作也可强制：
- 删除用户
- 修改权限
- 重置密码
- 导出数据
七、Google Authenticator 实现流程示例
绑定阶段
- 后端生成 secret
- 转为 QRCode
- 用户扫码
- 输入一次验证码确认
登录阶段
- 用户输入动态码
- 后端使用相同 secret 校验
- 时间误差允许 ±1 时间窗口
八、防止被暴力破解验证码
必须设置安全限制：
| 项目 | 建议 |
|---|---|
| 验证码错误次数 | 5次 |
| 锁定时间 | 10-30分钟 |
| 重发频率 | 每分钟一次 |
| 单日限制 | 10~20次 |
九、结合 Session 与设备风控的完美组合
最佳组合安全体系：
密码
+ 设备指纹
+ Session 风控
+ 2FA
+ 登录日志审计
风控联动方式：
- 新设备登录 → 强制 2FA
- 跨国家登录 → 强制 2FA
- 夜间异常登录 → 强制 2FA
- 多次失败 → 强制 2FA
十、落地建议（优先级）
实施顺序建议：
- 管理后台强制 2FA（邮件或 TOTP）
- 登录风控触发式 2FA
- 普通用户可选开启
- 重要操作再次二次验证
- 全平台 MFA 统一中心管理
十一、典型产品级功能清单
可以直接作为 PRD 或需求基础：
- 支持开启 / 关闭 2FA
- 支持 SMS / Email / Authenticator
- 强制绑定策略配置
- 二次验证安全日志
- MFA 密钥重置流程
- 备用恢复码（Recovery Codes）
- 登录设备列表查看
- 风险策略引擎触发 MFA
- 管理员强制执行策略
- MFA 健康度报表
十二、常被忽视的关键点
- 提供“备用恢复码”（一次性恢复 token）
- 扫码密钥必须加密存储
- 禁止明文返回 secret
- 更换设备必须走强验证流程
- MFA 变更要记录操作审计
十三、推荐默认方案（务实配置）
适合大部分企业系统：
✅ 管理后台必须 TOTP ✅ 普通用户默认短信 ✅ 新设备登录触发 2FA ✅ 高敏操作再次 2FA ✅ 提供恢复码 ✅ 登录日志可追溯
最后总结一句：
二次验证不是“多一道麻烦”，而是从“账号能被撞开”升级为“攻击成本指数级上升”的质变防线。
