查弱口令最怕两件事：一是把明文密码收集到自己手里（这本身就是新的风险），二是查完只得到一张「有 8 个弱口令」的名单却不知道怎么改。
先说清楚场景
弱口令的问题不在于「密码短」，而在于「可预测」。Company@2024、Fuyunxiong123、姓名拼音+生日，这类密码在任何一本攻击字典里都是前几页。
更麻烦的是变体：首字母大写、末尾加个 1 或 !，看起来复杂了，其实字典早就覆盖。所以「我们要求密码必须有大小写和符号」这条制度，对真正的弱口令几乎没有防御力。
该看的几项
- 不要收集明文。正确的做法是只读「强度标签」或做哈希比对，而不是让员工把密码报上来。收集明文等于你自己造了一个更大的泄露点。
- 先查关键账号。邮箱、财务系统、网银、NAS、ERP 后台、云控制台。这 6 类账号被攻破的后果，远大于普通办公账号。
- 查三个维度：是否在常见弱口令字典里（含变形）、是否包含公司名/品牌名/年份、是否与本人姓名或工号相关。
- 看复用。同一个密码用在多个系统，是比「密码强度低」更严重的问题——一处泄露，全线失守。
- 看二次验证。关键账号有没有开二次验证。开了二次验证，弱口令的危害会下降一个量级，但它不能成为不密码的理由。
常见的两个误区
- 误区一：只查长度。12 位的 P@ssw0rd2024 依然是弱口令。
- 误区二：改成「三月一换」。强制定期改密，实际结果是大家改成 Summer2024 → Autumn2024，可预测性更强。比起换得勤，不如一次设够长。
按这个顺序做
- 先给 6 类关键账号开二次验证——这是投入产出最高的一步，不需要全员配合。
- 用只读方式拿一份账号清单和强度标签（很多系统自带，不需要你看到明文）。
- 对命中的账号逐个改，改的时候用「四个不相关的词 + 数字」这种好记又长的形式，别用变形规则。
- 把「口令不含公司名、不含姓名与年份、长度 12 位以上」写进制度，并要求关键系统强制。
什么时候需要工具
如果你的账号清单不方便外发，可以用本地可逆变形通道：在浏览器里先把账号做可逆编码再上传，密钥只留在本地，平台看不到真实账号。
可以继续看
以上为通用自查思路，不构成安全认证、等保测评结论或法律意见。具体实施请结合实际系统与业务判断；涉及取证、事故处置时请联系专业机构。