密码策略制定：复杂度、过期、历史限制与常见误区
密码策略，说白了就是告诉用户“你的密码该怎么设、多久换一次、能不能重复”。表面上看几个规则很简单，但我在实际项目里踩过的坑比密码学的哈希碰撞还多。今天咱们把这四个维度掰开揉碎讲清楚，顺便把那些“常识”里藏着的雷点排一排。
核心原则：密码策略不是为了刁难用户，而是为了在安全性和可用性之间找平衡。过度苛刻的策略往往会逼出更危险的行为——比如把密码写在便签纸上贴显示器边框。
1. 复杂度要求：长度比花哨更重要
老派的复杂度规则都喜欢搞“至少8位，包含大小写、数字、特殊字符”。听起来挺安全是吧？我见过一个银行项目强制要求“必须有@#$三种符号之一”，结果用户把密码设成 Password1@，猜十次就破解了。
为什么？因为人脑记不住真正的随机，大家都往常见词上堆符号。NIST SP 800-63B 很早就改了风向：最小长度才是第一指标。建议至少12位，长度每增加一位，暴力破解的指数级增长才叫真安全。
| 策略维度 | 常见错误做法 | 推荐做法 |
|---|---|---|
| 字符种类 | 强制4种字符（大写+小写+数字+符号） | 只要求2-3种即可，重点放在长度 |
| 最小长度 | 8位（已不推荐） | 12位起步，内部平台建议16位 |
| 黑名单 | 只检查键盘顺序（如qwerty） | 用公共泄露密码库（如Have I Been Pwned API） |
我的经验：有一次给金融平台做改造，我用“密码Top1000榜单”测了现有用户，超过30%的密码都在那个列表里。后来强制集成黑名单检查，命中率仍然有8%。你以为用户会设复杂密码？大多数人只会取巧。
2. 过期时间：90天强制改？别闹了
传统做法是“每90天必须换一次密码”。这个规定从1980年代传下来，背后逻辑是“即使密码泄露了，90天后也就失效了”。但现实很骨感——用户每90天换一次，结果就是 Spring2024! → Summer2024! → Fall2024!，旧密码稍微变个年份和季节就出来了。
我参与过某跨国企业的内部平台改造，他们以前强制90天过期。后来我们调出了密码分析历史：70%的用户在变体模式里循环，安全增益几乎为零。而且频繁换密码让用户更容易忘记，从而增加找回密码的呼叫量——我亲眼看到IT服务台因为这个原因每天多处理200个工单。
NIST 2017年就改了口风：不要强制定期更换密码，除非你有证据怀疑密码已泄露（比如检测到撞库、爬虫攻击）。那什么时候换？只有两种情况：一是用户主动要求换，二是安全事件后强制重置。
注意：某些合规要求（如PCI DSS v4.0）仍然要求周期性更换。如果你必须遵循，至少把周期拉长到180天，并且配合防变体检查。我曾经帮客户在合规框架下争取到“12个月+安全事件触发”的方案——关键是把风险评估报告写扎实。
3. 历史密码限制：存够多少条才够用？
限制“不能重用最近N次”是为了防止用户在过期后立刻换回旧密码。常见的N是5到10。但这里有三个坑，我一个个说。
- 历史密码怎么存？ 不能存明文！必须存哈希。最简单的做法就是每次用户设置或更改密码时，把新密码哈希和之前的历史哈希逐个比对。如果匹配就拒绝。
- N值不是越大越好。 存20个历史哈希，每次登录都要遍历比对20次，哈希算法如果是bcrypt/scrypt，性能开销会累积。我见过一个系统因为存了50条历史，改密码接口响应时间从200ms飙升到2s。
- 区分“不能与当前密码完全相同”和“不能与最近N次相同”。 前者是最基本的要求——但很多平台连这个都没做好。后者针对的是“循环变体”问题。
// 伪代码：历史密码比对逻辑（使用bcrypt）
function isPasswordReused(newPassword, historyHashes) {
for(let hash of historyHashes) {
if(bcrypt.compare(newPassword, hash)) {
return true; // 命中历史密码
}
}
return false;
}
// 注意：历史列表最多保留N条（建议5-10），超出则剔除最旧的一条
个人习惯：我一般建议N=5。有人觉得太少，但你要想想——如果用户连续5次都换不成新花样，说明他的密码熵本身就低。与其放宽限制，不如直接提示“请重新设计一个真正不一样的密码”。
4. 常见误区：你以为的“安全”可能适得其反
- 误区一：复杂度指标越多越高。 其实“强制4种字符+最小8位”的组合算术结果（95^8 ≈ 6.6e15）远不如“只要求小写字母但最小16位”（26^16 ≈ 4.4e22）。长度是第一要素，特殊字符只是锦上添花。
- 误区二：过期时间越短越安全。 如前所述，频繁轮换的密码往往是弱变体。而且用户为了防止忘记，会在多个平台用同一密码——一旦泄露，等于连锁反应。
- 误区三：历史密码限制只防重复使用。 不防变体！比如
Abc@2023改成Abc@2024，哈希值完全不同，历史比对根本检测不出来。需要额外引入“相似度检测”或编辑距离检查——但这又会引起新的性能问题，我建议只在注册/修改密码时做一次，不要每个请求都跑。 - 误区四：忘了员工也需要守护。 企业内部开发者平台，高管账号、运维账号的密码策略往往和普通员工一样脆弱。我在一次渗透中，通过运维账号的弱密码直接拿到了整个K8s集群的权限。一定要对特权账号额外设置更严格的规则（比如强制FIDO2或硬件密钥）。
5. 一图看懂：如何制定合理的密码策略？
下面这张流程图展示了我常用的决策路径。从用户注册/修改密码开始，依次检查长度、黑名单、历史限制，最后决定是否接受。注意，过期时间部分引入了“事件触发”而非“固定周期”。
6. 总结：给你的平台定一套靠谱的策略
讲了这么多，我直接给一个最低可用的策略模板（适合大多数内部开发者平台）：
- 复杂度： 最小长度12位，不强制特殊字符，但必须检查公共泄露密码库
- 过期： 不设固定周期，只保留“当平台检测到异常登录行为”或“用户主动请求”的更换入口
- 历史： 保留最近5次密码哈希，禁止重复
- 额外： 对管理员、运维账号单独加一条：最小长度16位 + 强制启用多因素认证
最后提醒一句：再好的策略，也要配合用户体验设计。别让用户看到复杂的规则就直接放弃——给他们生成密码的按钮、密码强度实时反馈、甚至直接集成密码管理器API。我在改造某内部平台时，加了“一键生成符合策略的随机密码”后，用户满意度提升了30%，安全投诉下降了60%。