[two_factor]两步验证热

插件质量报告

插件：two_factor

颜色说明：黄色表示有数据读写，红色表示 Hook 在系统循环中执行，浅蓝色表示有文件写入。“列表跳过”表示回调在列表路径会提前返回，“回调内”表示操作位于回调自身或其帮助函数的循环体内。“文件批处理”表示逐个处理用户一次提交的文件，属于必要操作，不标记修正。只有操作实际处于需要优化的循环路径时，才会标记“修正❗️”。

数据字典

plugin_two_factor_users

plugin_two_factor_trusted_devices

正好需要

顶！

顶！

顶！

顶！

顶！

顶！

顶！

🔍 插件审查报告（对照《AI 开发规则》与开发者文档）

🔒 安全问题

低：plugin.php:108-113 恢复码由 bin2hex(random_bytes(4)) 生成，仅 8 位十六进制（约 32 bit 熵），偏弱。建议改为 random_bytes(8)（16 位十六进制 / 64+ bit）。其余安全面良好：登录拦截点正确（plugin.php:585-588 在 auth.password_verified 内 go() 拦截，未命中信任设备则不会走到 complete_login）；信任设备令牌仅存 SHA-256 哈希并每次轮换（205-235）；恢复码/密钥输出均 h()；TOTP 校验用 hash_equals（96）；验证页有 login_fail 限速（696-699）。

⚡ 性能问题

未发现明显问题。用户 2FA 状态与信任设备数均有请求级缓存（35-36、245-249），profile 钩子非红区，查询量可控。

🐛 功能/规范缺陷

低：plugin.php:632 op 同时读 $_POST/$_GET，且 setup/confirm/disable/reset_recovery/revoke_devices 等写操作未 require_post()；plugin.php:633-639 以 GET 访问 op=setup 会产生 upsert 写副作用。建议状态变更统一 require_post()、op 仅取 POST，GET 仅展示不写库。当前因密码+TOTP+CSRF 门禁不可被实际利用，属规范合规项。

✅ 修复优先级

1. 低：状态变更 op 增加 require_post() 并禁止 GET 写库。
2. 低：恢复码熵提升到 64 bit 以上。

🔍 插件审查报告（AI 自动审查，对照《AI 开发规则》与开发者文档；本插件未被 8/18 楼上 350 的报告覆盖，属独立首次审查）

插件：两步验证（two_factor）v1.1.8

🔒 安全问题
未发现明显安全问题。

⚡ 性能问题
未发现明显问题。

🐛 功能/规范缺陷
规范一致性建议：后台管理页函数体内未见显式调用核心 need_admin()（依赖核心 admin_page() 路由层统一鉴权兜底，当前不构成越权）；涉及写操作时判断请求方式使用手写的 $_SERVER['REQUEST_METHOD'] === 'POST'，效果等价于核心 require_post()，但写法与站内多数插件不一致。

✅ 修复优先级
低优先级：建议在后台页面函数内补充显式 need_admin()/require_post() 调用，作为纵深防御，避免未来核心路由调整时失去这层保护；不影响当前功能与安全性。

旧格式迁移：已将插件代码转存到开发日志，主题正文改为基础介绍。

版本 1.1.9 更新：
采用个人设置新hook