Flask默认不处理2FA验证流程，因其仅提供基础路由与扩展机制；flask-login管理会话但不涉及二次验证；flask-security虽支持2FA但硬编码模板与逻辑，自定义需手动解耦中间件链。
为什么 Flask 默认不处理 2FA 验证流程
Flask 本身只提供路由、请求响应和基础扩展机制，flask-login 管会话但不管二次验证，flask-security 虽支持 2FA，但默认启用 TOTP 且硬编码了模板和重定向逻辑，一旦你要对接短信网关、自定义验证页面或跳过部分敏感操作（比如管理员白名单绕过），就得手动拆解它的中间件链。真正卡住人的不是“怎么加验证码”，而是“在哪插钩子”——必须在用户已通过密码认证、但尚未执行敏感动作前拦截请求。
在视图函数里插入 TOTP 校验的正确时机
不能在登录时一次性完成 2FA（那只是增强登录安全），而要在调用敏感接口前单独校验。典型做法是：用户登录后，session['logged_in_with_2fa'] = False；访问 /delete-account 这类端点时，先检查该 flag，为 False 则重定向到 /verify-2fa 页面；校验成功后再设为 True 并允许后续若干分钟内的敏感操作。
- 用
pyotp.TOTP生成密钥时，务必用secrets.token_urlsafe(16)而非random，否则密钥可预测 -
pyotp.TOTP(user_secret).verify(input_code, valid_window=1)的valid_window=1表示允许当前窗口 ±30 秒，避免时钟偏差导致频繁失败 - 不要把
user_secret存进 session，只存一个短期有效的2fa_verified_until时间戳（如time.time() + 300），每次校验前比对
绕过 2FA 的合理例外怎么加才不破坏安全模型
某些场景确实需要豁免：比如运维人员从公司内网 IP 访问，或使用已绑定的硬件安全密钥（WebAuthn）登录。关键不是“要不要跳过”，而是“谁有权限跳过”和“依据什么跳过”。直接在视图里写 if request.remote_addr in INTERNAL_IPS: 是危险的——X-Forwarded-For 可伪造，必须由反向代理（如 Nginx）设置可信头，并在 Flask 中用 ProxyFix 显式信任。
- 用
flask-talisman或手动检查request.environ.get('HTTP_X_FORWARDED_PROTO') == 'https'，防止中间人篡改 IP 头 - 豁免逻辑必须放在 2FA 校验函数内部，而不是每个视图里重复写 if，否则容易漏掉新写的敏感接口
- 所有豁免条件应记录审计日志，例如：
app.logger.info("2FA bypassed for %s via IP %s", user.id, request.remote_addr)
短信验证码的临时状态怎么安全存储
别用 Redis 存裸手机号+验证码对（易被枚举），也别把验证码塞进 JWT（无法主动失效）。推荐方案：生成一个一次性的 verify_token（secrets.token_urlsafe(32)），关联手机号、验证码哈希（hashlib.sha256(code.encode()).hexdigest()）、过期时间，存入数据库带 TTL 的行（如 PostgreSQL 的 expire_at > NOW() 查询）；用户提交时只传 verify_token 和明文 code，服务端查 token 对应的哈希再比对。
立即学习“Python免费学习笔记（深入）”；
- 短信发送频率限制必须服务端实现，仅前端 disable 按钮毫无意义
- 验证码输入错误超过 3 次，应立即使对应
verify_token失效，而非单纯锁手机号——防止暴力穷举 token - 如果用 Twilio 或阿里云短信，回调地址必须带签名验证，否则攻击者可伪造“发送成功”事件
