去年冬天，弱口我帮一家小公司做安全巡检。令修登录他们的弱口后台管理系统，账号是令修 admin，密码是弱口 123456。我当时愣了两秒——这系统里存着几千条客户信息，令修包括手机号和家庭住址。弱口更离谱的令修是，数据库的弱口 root 密码也是同一个。运维的令修人跟我说，这密码用了三年，弱口没人改过，令修因为“改了怕忘”。弱口

弱口令这事，令修说到底不是弱口技术问题，是人的问题。你装再贵的防火墙，架再多的 WAF，只要有人把密码设成 admin888，一切都白搭。攻击者根本不需要什么零日漏洞，他们手里有字典，有自动化脚本，几秒钟就能跑完几万个常见密码组合。你的系统在人家面前，跟没锁门一样。

我见过最夸张的一个案例，是某地一个政务系统。前端页面看着挺正规，结果后台登录口用 Burp Suite 一跑，发现用户名是 test，密码是 test123。进去之后能看到整个区的网格化管理数据。这事后来被通报了，但根源就是开发阶段图省事，上线前也没人认真检查。

怎么修？先别急着上什么密码策略。第一步，把现有系统里所有账号的密码哈希导出来，用 hashcat 跑一遍常见字典。这一步能筛出大部分弱口令。别嫌麻烦，这比事后被拖库强。我们那次巡检，一个下午就跑出了十几个账号，全是 888888、qwerty 这种。

第二步，强制改密。但别搞那种“必须大小写加数字加符号”的硬性规则，用户会直接把密码写在显示器边上。更好的做法是设一个最小长度，比如 12 位，然后检查是否在泄露密码库里。现在有很多开源的泄露密码库，比如 Have I Been Pwned 的离线版，拿来做比对很方便。密码不在库里，长度够，基本就安全了一大半。

第三步，上多因素认证。短信验证码虽然被诟病，但比没有强。条件允许的话，用 TOTP 或者硬件密钥。我们给那家公司修完之后，后台登录加了 Google Authenticator，运维的人一开始嫌烦，后来发现手机丢了也不怕，反而踏实了。

还有一点容易被忽略：默认口令。很多设备、中间件、数据库装完就有默认账号，比如 Tomcat 的管理台、Redis 的未授权访问。这些东西不归应用管，但一样能进内网。修复的时候得把这些也扫一遍，该禁用的禁用，该改的改。

最后说个实在的。弱口令修复不是一锤子买卖。你今天改完，明天可能又有人设个 123456。得定期跑扫描，得让开发在代码里就做密码强度校验，得让运维养成改密习惯。安全这事，没有终点，只有不断修补。但至少，别让 admin/123456 成为你系统的入口。