4. 密码策略设计原则：从复杂度到锁定机制
密码策略这东西，说起来好像就是定几个规则。但我在实际项目里踩过不少坑，才发现它是个系统工程。你想想看，物联网设备数量动辄成千上万，密码策略要是设计得不好，要么被黑客轻松攻破，要么把运维人员逼疯。
今天我就把密码策略拆成四个核心维度来讲：复杂度、长度与字符集、有效期与历史记录、账户锁定。每个维度我都会结合实战经验，告诉你哪些是必须守住的底线，哪些是可以灵活调整的。
核心观点：密码策略不是越严越好，而是在安全性与可用性之间找到平衡点。物联网场景下，设备无人值守、批量部署、弱计算能力等特点，让密码策略设计比传统IT系统更棘手。
4.1 密码复杂度要求：别让规则变成摆设
密码复杂度，说白了就是要求密码不能太「好猜」。我见过太多设备出厂密码是 admin123、password 这种，黑客都不用动手，直接猜就能进去。
那到底什么样的复杂度才算合格？我个人习惯参考 NIST SP 800-63B 和国内等保2.0的要求，把它们揉在一起用：
| 复杂度要素 | 基本要求 | 推荐要求（物联网场景） |
|---|---|---|
| 大写字母 | 至少1个 | 至少1个 |
| 小写字母 | 至少1个 | 至少1个 |
| 数字 | 至少1个 | 至少1个 |
| 特殊字符 | 可选 | 至少1个（!@#$%^&*等） |
| 禁止连续字符 | 建议 | 必须（如 abc、123、qwerty） |
| 禁止重复字符 | 建议 | 必须（如 aaa、111） |
| 禁止键盘序列 | 可选 | 必须（如 asdf、zxcv） |
我的实战经验：有一次给某智能水表厂商做合规整改，他们原来的密码策略只要求6位数字。我建议改成「8位以上+大小写+数字+特殊字符」。结果运维团队炸了锅，说设备批量注册时根本记不住。后来我们折中了一下：初始密码用复杂随机串，首次登录强制修改，同时支持二维码扫码登录。问题就解决了。
这里有个坑要注意：复杂度规则不能太死板。比如要求「必须包含大小写字母、数字、特殊字符」，结果用户把密码设成 Passw0rd!——看起来合规，实际上脆弱得要命。我建议在复杂度检查之外，再加一个「常见弱密码黑名单」：
# 弱密码黑名单示例（部分）
weak_passwords = [
"password", "password123", "admin", "admin123",
"123456", "12345678", "qwerty", "qwerty123",
"letmein", "welcome", "monkey", "dragon",
"Passw0rd", "Passw0rd!", "Admin123", "Admin123!"
]注意：黑名单要定期更新。我见过有些厂商的黑名单还是2015年的，连 P@ssw0rd 这种经典变种都没收录。建议每季度从公开泄露密码库中提取新条目。
4.2 密码长度与字符集：长度才是硬道理
很多人以为复杂度比长度重要，其实恰恰相反。你想想看，一个12位的纯数字密码，组合数是10的12次方；一个8位的「大小写+数字+特殊字符」密码，组合数大约是95的8次方。算下来，12位纯数字的破解难度其实更高。
我个人的建议是：长度优先，复杂度辅助。具体来说：
- 最小长度：物联网设备建议12位起步。如果设备计算能力太弱（比如某些MCU），至少也要8位。
- 字符集：至少包含小写字母、大写字母、数字。特殊字符建议加上，但不要强制要求——有些嵌入式系统的键盘输入特殊字符很麻烦。
- 最大长度：不建议设上限。但要注意，有些老设备对密码长度有限制（比如只支持16位），这时候要兼容处理。
| 密码长度 | 纯数字 | 小写字母 | 大小写+数字 | 全字符集 |
|---|---|---|---|---|
| 6位 | 1秒内 | 1秒内 | 1秒内 | 几秒 |
| 8位 | 几秒 | 几分钟 | 几小时 | 几天 |
| 10位 | 几小时 | 几天 | 几个月 | 几十年 |
| 12位 | 几个月 | 几十年 | 几千年 | 几万年 |
注：以上为离线暴力破解估算，假设每秒10亿次尝试（GPU集群）。实际物联网设备多为在线破解，速度慢得多。
关键结论：12位密码，哪怕只用小写字母，也比8位「大小写+数字+特殊字符」更安全。所以别纠结字符集了，先把长度提上去。
4.3 密码有效期与历史记录：换得太勤反而坏事
关于密码有效期，业界其实有过争论。以前大家都觉得90天换一次密码是金标准，但后来研究发现，换得太勤会导致用户把密码写成「Passw0rd1」「Passw0rd2」「Passw0rd3」这种序列——安全性反而下降。
我个人现在的做法是：
- 有效期：物联网设备建议90-180天。如果是暴露在公网的关键设备（比如智能网关），可以缩短到60天。内网设备可以放宽到180天甚至一年。
- 历史记录：保留最近5-10条历史密码，禁止重复使用。这个数字怎么来的？我测试过，保留5条能挡住90%的「序列式改密码」，保留10条基本能挡住99%。再多就没必要了，存储开销也大。
我曾经踩过的坑：给某智能门锁厂商做方案时，我建议密码有效期设成30天。结果三个月后回访，发现80%的用户把密码贴在了门锁背面。后来改成了180天，配合「首次登录强制修改」和「异常登录提醒」，安全性反而提升了。所以啊，别为了合规而合规，要考虑实际使用场景。
这里还要注意一个细节：密码过期提醒。物联网设备不像电脑，用户不会天天登录。我建议在设备管理后台设置提前7天提醒，同时支持「延迟更换」功能（最多延迟30天），避免用户因为忙不过来而直接禁用密码策略。
4.4 账户锁定策略：别把好人锁在外面
账户锁定策略，目的是防止暴力破解。但设计不好，反而会变成攻击者的武器——他们可以故意输错密码，把合法用户锁在外面，造成拒绝服务。
我总结了一套「三级锁定」策略，在多个项目中验证过效果不错：
- 第一级（警告）：连续3次失败，记录日志并发送告警（不锁定）。
- 第二级（临时锁定）：连续5次失败，锁定15分钟。15分钟后自动解锁。
- 第三级（永久锁定）：连续10次失败，锁定账户，需要管理员手动解锁。
| 失败次数 | 动作 | 说明 |
|---|---|---|
| 1-2次 | 无操作 | 正常输入错误，不处理 |
| 3次 | 记录日志+告警 | 通知管理员或用户本人 |
| 5次 | 临时锁定15分钟 | 自动解锁，无需人工干预 |
| 10次 | 永久锁定 | 需管理员手动解锁 |
重要提醒：锁定策略要考虑分布式场景。如果设备有多个登录入口（比如Web端和API端），失败次数要合并计算，否则攻击者可以轮流攻击不同入口，绕过锁定机制。我见过一个案例，攻击者通过API接口每秒尝试100次密码，而锁定策略只针对Web登录——结果API端成了后门。
另外，锁定策略还要考虑「解锁机制」。我建议提供两种解锁方式：
- 自动解锁：临时锁定到期后自动恢复，不需要人工操作。
- 手动解锁：永久锁定后，管理员通过后台或物理按键解锁。注意，解锁操作要记录日志，防止滥用。
嗯，说到这里，密码策略的四个核心维度就讲完了。你可能会问：这些规则怎么落地到物联网设备上？别急，后面几章我会专门讲密码策略的配置模板、自动化检测工具，以及如何跟合规要求对标。今天就先消化这些基础原则吧。