无源码系统实现弱口令检测与自助密码重置方案

摘要：针对无源码权限的遗留业务系统，本文提出一种"前端拦截 + 独立密码服务"的双层治理方案。通过应用服务器层注入检测脚本实现登录拦截与引导，配套部署独立的密码重置服务完成数据库直写，在零侵入业务代码的前提下，实现弱口令检测与自助密码重置的闭环管理。

一、背景与问题

企业信息系统运行多年后，常面临以下困境：

弱口令普遍存在
：用户习惯使用简单密码，如连续数字、键盘序列、重复字符等；
源码不可修改
：系统为外购或历史遗留，无源码或源码丢失，无法在后端增加密码复杂度校验；
改造风险高
：直接升级系统版本或更换认证模块，可能引入兼容性风险，影响业务连续性。

传统方案（如 WAF 规则拦截、数据库强制策略）要么无法精准提示用户，要么无法引导用户自助修改。本文方案的核心思路是：在不改动业务系统一行代码的前提下，通过部署层手段实现弱口令治理闭环。

二、整体架构

方案由两层组成：

┌─────────────────────────────────────────┐│ 第一层：前端检测与拦截（应用服务器注入） ││ 登录页 → 注入检测脚本 → 弱口令拦截 ││ ↓ 弹窗引导 │└─────────────────────────────────────────┘ │ ▼┌─────────────────────────────────────────┐│ 第二层：独立密码重置服务 ││ 验证旧密码 → 新密码复杂度校验 → 数据库直写 ││ ↓ 返回登录 │└─────────────────────────────────────────┘

第一层部署在业务系统的应用服务器（如 Tomcat）上，通过修改登录页模板注入 JavaScript 检测脚本。该脚本在浏览器端实时检测密码强度，拦截弱口令提交，并弹出模态框引导用户跳转至密码重置页面。

第二层为独立部署的密码重置服务，支持 Oracle、SQL Server 等主流数据库。服务直接操作用户认证表，验证旧密码（支持 MD5/SHA/明文等多种加密格式）后写入新密码，全程无需业务系统参与。

三、关键技术设计

3.1 前端检测脚本的注入方式

检测脚本通过 sed 在登录页 </body> 标签前插入 <script> 引用实现加载。脚本核心能力包括：

检测维度	规则说明
长度检测	密码长度 ≥ 8 位
弱口令字典	覆盖 Top 30 常见弱口令及键盘序列（qwerty、1qaz2wsx 等）
重复字符	拦截 `111111`、`aaaaaa` 等
纯数字	拦截纯数字密码
用户名关联	密码包含用户名子串时拦截

事件拦截机制：采用 DOM 事件捕获阶段（useCapture = true）绑定登录按钮的 click 事件，确保在 ExtJS、React 等前端框架的事件处理之前执行拦截逻辑。对于动态渲染的组件，通过 MutationObserver 持续监听 DOM 变化，延迟初始化直至密码输入框和登录按钮渲染完成。

3.2 独立密码重置服务的设计

服务采用 Minimal API 架构，仅暴露两个端点：

GET /api/health
：返回当前数据库配置与加密方式，用于部署验证；
POST /api/reset-password
：接收用户名、旧密码、新密码、确认密码，执行校验与更新。

密码加密适配：通过 ComputeMd5() / ComputeSha1() 等工具方法，在验证和写入环节分别对旧密码和新密码进行加密，确保与数据库现有存储格式一致。若数据库采用加盐哈希，则需同步配置盐值与算法逻辑。

数据库配置化：表名、用户名字段、密码字段均通过 appsettings.json 配置，无需修改代码即可适配不同系统的用户表结构：

{ ”PasswordReset”: { ”ConnectionString”: ”...”, ”Provider”: ”Oracle”, ”TableName”: ”SYS_USER”, ”UserNameField”: ”USER_NAME”, ”PasswordField”: ”PASSWORD” }}

3.3 前后端联动机制

前端拦截弹窗提供两个操作按钮：

"我知道了"
：关闭弹窗，用户自行修改密码后重试；
"修改密码"
：通过 window.open() 在新标签页打开密码重置服务，并通过 URL 参数 ?username=xxx 自动带入当前用户名，减少用户输入成本。

四、实施要点

4.1 多节点一致性

若业务系统前端通过负载均衡（如 Nginx）分发至多台应用服务器，每台后端节点均需独立注入检测脚本。任何一台未注入，都会导致部分流量绕过检测，形成安全短板。

4.2 应用服务器实例确认

当目标服务器存在多个应用服务器版本（如 Tomcat 7 与 Tomcat 8 并存）时，必须通过 netstat / ss 确认实际监听标准端口（80/443）的进程路径，避免将脚本放置于未生效的实例目录。

五、安全边界与局限性

本方案属于缓解措施（Mitigation），而非根治方案（Remediation），其安全边界如下：

层面	有效范围	局限性
前端脚本	拦截普通用户的弱口令提交	无法阻止禁用 JavaScript 的浏览器、无法阻止直接调用后端 API 的恶意请求
应用服务器注入	零侵入业务代码，部署层可控	依赖应用服务器重启生效，浏览器可能缓存旧版登录页
独立密码服务	直接更新数据库，绕过业务系统认证	不能替代数据库原生密码策略、不能替代多因素认证（MFA）

长期建议：

数据库层启用原生密码复杂度策略（如 Oracle PROFILE、SQL Server CHECK_POLICY）；
逐步推动业务系统接入统一身份认证（IAM）或堡垒机，收敛本地账户；
建立季度弱口令扫描机制，对存量账户进行强制重置。

六、结语

对于无源码或源码不可修改的遗留系统，安全加固往往受限于"动不了代码"的困境。本文提出的"服务端注入 + 独立服务"方案，通过将安全控制点前移至应用服务器层和浏览器层，在零侵入业务代码的前提下实现了弱口令检测与自助重置的闭环。该方案适用于短期应急治理，同时为企业争取了向统一身份认证架构迁移的过渡时间。