密码必须90天改一次吗？我把它改成永不过期之后，和审计吵了一下午

一、那个"每90天准时改密码"的同事

2023年11月14日，下午三点十七分。安全运营的老王在群里发了张截图：我们一个供应链部门的账号，在40分钟里从新加坡、荷兰、巴西三个IP地址登录失败了4次，第5次成功了。

组策略里的账户锁定阈值是10次/30分钟。攻击者要么知道这个数，要么就是运气好——反正我们的告警一条都没响。

我拉日志追下去，那个账号的密码是 公司拼音@2023。改密记录显示2023年9月3日刚改的，完全符合我们的密码策略：最短8位、必须含大小写字母和数字符号、最长使用期限90天。这位同事没有做错任何事，他认认真真按规矩改了密码，只是他改出来的东西，在hashcat眼里约等于没改。

我把这个密码丢进本地那台跑着hashcat的机器，用rockyou.txt（14344391条）加上best64规则跑。不到4秒就出来了。

那一刻我盯着屏幕看了挺久。2016年定这条策略的人，和2023年被撞库的人，其实都没有做错什么，但结果就是这样。

二、我去把NIST和微软的文档重新翻了一遍

NIST SP 800-63B，2017年发布、2020年3月更新到rev3，5.1.1.2节写得很直接：验证方不应该强制用户周期性地更换记忆密钥，除非有证据表明该密钥已被泄露或存在被攻破的迹象。

微软的动作更干脆。2019年5月发布的Windows 10 v1903安全基线里，直接把"密码最长使用期限"的默认值删掉了。在那之前，活动目录的默认域策略是42天——我至今不知道42这个数字是谁拍出来的。

那我们的90天是从哪来的？翻档案，2016年做PCI DSS认证，8.2.4条款写着"至少每90天更换一次用户密码"。从那天起，这条就焊死在我们的基线文档里，七年没人动过。期间换了三任安全负责人，谁也没质疑过它。

这里我要说一个可能有点得罪人的判断：周期性改密码这套东西，降低的风险非常有限，但它能把风险转移出去。安全部门用一个可量化的指标（我们每个季度都强制所有人改了一次密码）证明自己工作了，代价由全体员工的记忆力和IT服务台的人力承担。真正的高危资产——服务账号、共享账号、没有MFA的入口——反而一条都没被这条策略覆盖到。

三、我们实际改了什么（这一节可以照抄）

改之前先做好一件事：跑一遍 Get-ADUser -Filter * -Properties PasswordLastSet,PasswordNeverExpires | Export-Csv，导出全量密码年龄清单。这一步别省，后面出问题要回溯。

1. 最长使用期限：90天改成0。 在AD里，0就是永不过期。改的是Default Domain Policy，不是某个OU的细粒度策略，改之前确认没有子OU覆盖。

2. 最短密码长度：8位提到16位。 只提长度不提复杂度，很多人会不理解。但长度带来的搜索空间增长是非线性的，16位哪怕是纯小写+数字，暴力破解的成本也远高于8位带符号。

3. "密码必须符合复杂性要求"这一项，我们保留了。 说实话它拦不住有心人，但能挡住把密码设成6个1的极端懒人。真正的防线放在下面这条。

4. 泄露密码黑名单。 这是整件事里最有效、也最费劲的一步。我们下载了Have I Been Pwned的Pwned Passwords离线库，SHA-1格式，8亿多条，解压后将近35个G。这东西没法直接塞进AD，所以做成了一套自助改密接口的前置校验：用户提交新密码时先哈希查库，命中直接拒绝，并提示"这个密码在历史泄露库中出现过"。

5. 加了条自定义规则： 新密码不得包含公司名、产品名、季节+年份的组合，比如 Spring2024、Summer@2024 这类。用正则写的，一共9条规则，维护成本不高。

6. MFA覆盖率：VPN 100%、O365 100%、堡垒机 100%。 这条其实是上面所有措施的前提。我是先确认MFA覆盖率到100%，才敢动轮换策略的。如果覆盖率只有70%，那免谈。

7. LAPS接管本地管理员密码。 Windows LAPS在2023年4月已经内置到系统里了，不用再单独装老版本。我们给200多台终端的本地管理员密码统一设成20位随机、30天轮换，备份存在AD里。

8. 监控规则调整。 盯着4625（登录失败）和4740（账户锁定），加了一条：同一账号在10分钟内出现3个以上不同省份或国家的源IP，直接告警。这个比锁定阈值灵敏得多，因为攻击者为了不触发锁定，每次可能只试3次——但源IP的分散程度是藏不住的。

四、审计那天，我们从两点吵到五点

2024年3月，ISO 27001监督审核和一个客户方合规检查撞到一起了。审计老师翻到我的密码策略文档，看到"最长使用期限：无"，笔停在半空。

他引用的是PCI DSS 3.2.1的8.2.4条款。我说我们这套AD不承载持卡人数据，不在PCI范围内。他说那你怎么保证合规基线的一致性。

我说NIST SP 800-63B和微软安全基线都不建议定期轮换，理由会训练出可预测的密码模式。

他反问我一句，我到现在还记得原话："你怎么证明'有证据表明密码已被泄露'？你没有这个检测能力的时候，定期改密是不是至少算个兜底？"

我哑了。说真的答不上来。我们确实没有持续检测密码泄露的能力——HIBP只是个快照，查的是"历史上泄露过"，不是"正在泄露"。

最后的妥协方案是这样：不做全量强制轮换，但对三类账号保留180天强制改密——服务账号、共享账号、以及持有本地管理员权限的账号。理由是这三类覆盖不到MFA，密码就是唯一防线。

审计那边最后签字了，但给我们开了一项"观察项"，写的是"密码生命周期管理机制需进一步完善"。这话什么意思我也没完全琢磨透。

五、改完一年多的数据

• IT服务台的密码重置工单：改之前每月317个上下，占全部工单的四成多；改之后稳定在55到70个每月。省下来的人力我们事先没预料到。
• 撞库成功事件：2023年全年6起（密码确实被撞对了，全是靠MFA最后拦下来的，但每次都要发告警、写报告）；2024年4月到2025年3月，0起。这个数据我不敢说满，样本时间还是太短。
• 钓鱼演练点击率：13.7%降到6.2%。但我不确定跟密码策略有多大关系，中间我们还换过一轮培训内容，变量没控住。
• 内部小样本测试：我们自己的审计员拿30个真实NTLM哈希跑了一晚上，改策略前命中11个，改策略后命中0个。样本太小，只能当个参考，别拿去做汇报。

六、几件我到现在也没想明白的事

第一是服务账号。 我们域里有400多个服务账号，大部分密码设于2015年之前，最老的一个已经用了3400多天。它们不会过期，没有MFA，改一次动不动搞崩生产。每次打开这份清单，我都觉得前面那些工作像是在漏水的船上擦甲板。

第二是共享账号。 产线上有12台设备的登录账号是所有人共用的，密码就贴在机柜内侧。HIBP查不到它——因为它本来就已经是公开的，算不上"泄露"。

第三，也是最要命的一条。 我们所有关于密码的讨论，都建立在"密码是挡住攻击者的第一道门"这个假设上。但从这两年的实战看，攻击者更多在绕开密码：钓鱼拿OAuth token、从初始访问经纪人手里买入口、打第三方供应商的API。密码策略做得再漂亮，也拦不住有人点错一次授权弹窗。

所以如果有人问我密码要不要90天改一次，我的回答是：先去看你的MFA覆盖率。到100%了，可以谈取消轮换；没到100%，别折腾，老老实实继续改。

这个回答我自己都觉得挺别扭的。因为它意味着，大多数公司其实应该继续做那件已经被证明没多少用的事——至少在MFA铺开之前。