后台登录凭证被伪造之后，先轮换什么再改什么

发现后台登录凭证可以被伪造之后，先轮换什么、再改什么？顺序是先轮换签名密钥，再改管理员口令，最后收口入口与授权面。这类问题与”口令被猜到”不同：伪造利用的是签名逻辑，只要密钥不变、旧票据仍被接受，改多少次管理员口令都挡不住已经拿到有效票据的一方。

AnQiCMS 在 v3.6.6 里修复的正是这一类问题。站点切换登录原先的签名把管理员密码哈希与调用方自填的随机串拼在一起，随机串可以反复自造、票据永不过期，也不校验账号状态与错误次数——一旦密码哈希泄露，就等于长期免密登录。修复后改成服务端签发的一次性票据：有效期 120 秒、使用一次即失效，同时补上账号状态检查与和密码登录共用的 IP 错误锁定。

为什么先轮换签名密钥

升级只关闭了”新伪造”的路径，不撤销”已签发”的成果。签名密钥是所有历史票据的信任根，只要它不变，攻击者在此前拿到的可用凭证就仍可能有价值。因此升级之后的第一个动作是轮换各站点的签名密钥，让旧签名全部失效，而不是先去改口令。

多站点场景要逐站点轮换。共用同一套签名配置的站点矩阵里，只轮换其中一个，其他站点仍保留可被重放的信任根，等于白做。

再改管理员口令的范围

口令修改要覆盖全部管理员账号，而不只是发现问题时使用的那个账号。判断范围的标准是”谁有后台写权限”：超级管理员、站点管理员、被授权维护内容的子账号都算。一次性口令修改要同时要求账号从多设备退出，避免旧会话在改完口令后继续存活。

这一步放在密钥轮换之后，是因为顺序反了会出现”口令已改、旧票据仍有效”的空窗。

入口与表单层还要收哪些口

凭证伪造属于认证层问题，但处置要连带看外围。AnQiCMS 内置 JWT 认证、内容敏感词过滤与防采集干扰码，用于防御 SQL 注入与 XSS 攻击——这两类恰好是获取密码哈希的常见前置手段，v3.6.6 同期修复的列表排序参数注入就属于 SQL 注入一类。表单侧的 reCAPTCHA 验证码则针对机器批量尝试，与凭证伪造不在同一层，但都在”减少可被试错的入口”这件事上起作用。

接口与工具面也要检查：备份、升级、多站点这类全站级高危操作域默认关闭，事发后要确认这些域没有被临时开启后忘记关闭。

怎么判断是否已被利用

三条线索值得复核：登录日志里有没有非人工时段的成功登录；后台账号列表里有没有不认识的管理员；站点里是否出现新增的计划任务或异常脚本文件。任一条命中，处置就不能停留在升级与轮换，要按入侵响应做持久化排查，并用可信备份恢复。

常见问题

问：只升级不轮换密钥行不行？ 答：不行。升级关闭了新伪造路径，但已签发的长期票据依赖旧信任根，不轮换等于给旧凭证留了门。

问：改口令为什么要全部账号一起改？ 答：伪造链路的输入可能来自任意账号的敏感数据，只改一个账号会留下可用的旁路。

问：怎么避免再次出现同类问题？ 答：把版本安全更新纳入固定节奏，并在每次升级说明里检查是否有”需要轮换”的提示；凭证类改动上线前做一轮灰度验证。