弱口令整改措施，先锁账号还是先改密码

顺序反了，力气基本白花。我见过一个后台被扫描器盯上，值班的人第一反应是把所有账号密码重置一遍，忙到后半夜，结果没过几天又被人登进去了——因为那个能匿名访问的测试接口压根没人管，密码改得再勤也是白改。所以先锁账号还是先改密码这个问题，我的答案是先锁、再改、最后才收紧策略。这个顺序不是拍脑袋定的，是因为弱口令之所以危险，前提是攻击者能反复试，你把这个能反复试的口子先收住，后面的活才有意义。

弱口令整改措施第一步：先把门关上再换钥匙

用一句话说清楚弱口令的本质：不是密码难看，是它太好猜而且能被猜很多次。撞库、爆破这两条路子，都需要一个稳定的尝试入口。那把入口限住——限制来源 IP、失败几次就暂时锁定、管理端口不对全网开放、测试账号和演示账号直接删——见效速度比改密码快得多，而且不影响日常业务。改密码是钥匙的事，关入口是门的事，门开着换再好的锁芯也没用。

还有一个现实问题：改密码是全员动作，要走通知、要人配合、要处理登录失败的投诉。锁入口是运维一个人的事，几十分钟能搞完，风险还先降下来一截。哪个先做，其实从投入产出上就分出来了。

锁账号锁的是入口，不是把人锁在外面

一听到锁账号，很多人的理解是全员禁用账号，这肯定要出事，业务一停投诉立刻上来。我讲的锁，是把那些不该对外开着的东西收起来：远程管理的默认端口，默认的 admin、test、demo 这类账号，离职很久还在的账号，三五个月没登录过的僵尸号，还有那些为了方便临时开的、后来谁都忘了关的调试页面。

做法上别一刀切。先导一份账号清单，按“最近登录时间”“来源 IP 范围”“权限等级”过一遍，能删的直接删，不能删的先降权再限制登录来源。降权比禁用温和，业务方也容易接受。这一轮走完，你再去推改密码，遇到的阻力会小很多。

改密码这一步，多数人改不到点子上

最常见的操作是登录面板点一下“重置”，生成一串看着挺复杂的东西，然后发给一堆人，密码在聊天记录里飞来飞去。这不叫整改，这叫把弱口令换成了“流传在群里的口令”。真要改，得盯着两件事：一是不复用，同一个密码别在后台、数据库、跳板机上通用；二是不用可预测的素材，公司名、域名、年份加上几个数字，这类东西在字典里排得很靠前。

批量改的时候有几个坑得提前想。别从唯一的那个管理通道下手，先把带外控制台或者另一条登录途径确认能用，再动线上的密码；改完立刻测一次登录，别等第二天才发现进不去。有会话的系统，改密码会让部分在线用户掉线，挑低峰时段做。这几条都是被坑过才记住的，说起来简单，急起来最容易漏。

还有一类账号压根没密码这回事，却一样是弱口令级的风险——中间件的默认配置、数据库的 root 远程登录、对象存储的管理密钥、接口的长期 token。它们不出现在“改密码”的名单里，因为没人把它们当成账号。弱口令整改措施真要落地，这类必须单独列一张表，一个个过，只改人名账号是不够的。

密码策略别把用户逼成对手

策略这块我看法比较直接：长度下限比复杂度要求更管用，禁用常见弱口令字典、禁止键盘序、禁止和用户名高度相似，再叠加关键系统的二次验证，这套组合比“必须同时含大小写数字符号”靠谱得多。后面那种规则，实际效果是把人逼去设 Abc123! 这种更好猜的东西，形式上过了，实质上没变。

策略也别定得比业务还硬。改密码周期太短，用户就开始记快捷键、写便签、互相传，风险反而升高。关键系统严一点，普通后台松一点，分级处理比一把尺子量到底现实。

整改完怎么判断是真过了，不是纸面过了

验证不用搞得很复杂。内网再扫一遍，看还有没有默认口令和匿名可访问的服务；翻登录日志，看失败次数有没有异常集中的来源；把账号清单再对一遍，确认没冒出新的默认账号；最后是留痕，通知发了没、谁改的、什么时候改的，这些记录在审计或者检查的时候用得上。具体的合规口径和配置项，以服务商文档或官方页面说明为准，别照抄网上的模板。

我一般建议把这几步排成一个时间表：入口收缩当天做完，账号清理一周内，密码批量替换和策略上线排到低峰窗口，验证放到最后。别一次性全压在同一天，出了问题你连是哪一步动的都分不清。

回到开头那个问题：先锁账号。锁的是入口和不该存在的账号，不是把人挡在门外；然后才是改密码，重点是别复用、别用可猜的素材；策略收紧放最后，它是长期约束，不是应急手段。这三步顺序乱了，最常见的结局是折腾一圈、业务挨骂、漏洞还在。