平台存在弱口令漏洞的平台整改报告

3月17日凌晨，安全巡检日志里跳出一条刺眼的存弱记录——运维后台的admin账户在2分钟内被连续尝试登录17次，其中6次密码输入为“admin123”。口令这不是漏洞巧合，是改报告有人拿字典在撞库。更让我后背发凉的平台是，该账户绑定的存弱手机号是五年前离职员工的虚拟号，早已停机。口令

漏洞不是漏洞被黑客攻破的，是改报告被我们自己“惯”出来的。这个弱口令从平台上线那天就存在，平台中间换过三任运维负责人，存弱没人动过它。口令因为“能用”，漏洞因为“麻烦”，改报告因为“反正内网有防火墙”。可现实是，防火墙挡得住外部的扫描，挡不住内部对安全的漠视。

我花了半天时间翻审计日志，发现类似情况不止一处。测试环境里，有6个账户口令与用户名完全相同；某个第三方接口的token直接明文写在配置文件中；还有两台跳板机的密码是“Qwer1234”，属于典型的键盘序列弱口令。这些不是技术难题，是管理惰性。

整改从当天下午开始，没搞动员大会，直接动手。第一件事是强制全平台密码策略升级——长度不低于12位，必须包含大小写字母、数字和特殊符号，同时禁止与用户名或手机号存在子串匹配。光改策略没用，得让旧密码失效。我写了个脚本，对所有账户执行“密码过期强制重置”，并关闭了“记住密码”功能。有人抱怨麻烦，我回了一句：嫌麻烦的人，等被薅羊毛的时候更麻烦。

第二件事是给所有特权账户上双因子认证。以前觉得短信验证码就够，但考虑到短信有被劫持风险，干脆上了TOTP动态令牌。每个运维人员手机装一个认证器，登录时除了密码，还要输6位一次性验证码。这个动作不大，但直接把暴力破解的窗口期从“无限次尝试”压缩到“最多5次”。

第三件事最琐碎，也最容易被忽略——清理僵尸账户。我拉出近一年无登录记录的账户清单，逐个核实，该关的关，该删的删。有个账户是某合作商的技术支持，项目早结束了，权限还挂在生产库上。这种“看不见的入口”比弱口令更危险，因为你不知道它什么时候会被激活。

整改不是一次性动作。我建了个每周自动扫描任务，对全网段做弱口令探测，用同样的字典去撞自己的系统。撞开了就记一笔，第二天晨会点名。头两周抓到三个漏网之鱼，都是新入职员工图省事设的简单密码。后来在入职安全培训里加了一节实操课，让新人亲手尝试破解一个弱口令虚拟机，感受下“被攻破”是什么体验——效果比讲十页PPT好得多。

到现在过去两个月，再没出现一例弱口令告警。但我不敢说彻底解决了。安全是动态对抗，今天设了复杂密码，明天可能有人把它写在便利贴上贴在显示器边框。所以我把整改报告的最后一段留给了“下一次”——下一次审计在6月1日，下一次密码强制更新在9月，下一次新员工培训在下周一。漏洞补上了，但漏洞背后的习惯，得靠日复一日地拧螺丝。