口令策略核查查什么
口令策略的有效性只有一条判断标准：服务端是否强制执行。前端提示长度不足或强度不够，只是体验优化，绕过前端直接提交请求就能验证。核查因此分两层：策略本身是否合理（长度下限、是否比对弱口令字典、历史口令限制、是否限制修改频次），以及策略在各入口是否一致执行（注册、改密、管理员重置、批量导入）。验证要在自有测试账号上进行，避免触发真实账号锁定。
基本信息
| 核查面 | 策略配置、注册与改密校验、服务端强制执行 |
|---|---|
| 要点 | 长度下限、弱口令字典比对、历史口令与修改频次限制 |
| 验证方式 | 用自有测试账号提交弱口令，观察服务端是否拒绝 |
| 一致性 | 注册、改密、管理员重置、批量导入都应执行同一策略 |
| 纪律 | 不在真实用户账号上试探，避免触发锁定 |
典型使用场景
- 系统上线前的账号安全基线核查
- 评估弱口令治理：是否存在可猜解的业务相关口令
- 管理员重置流程核查：重置后的初始口令是否强制修改
- 批量导入流程核查：这类入口常绕过全部策略校验
- 修复验证：确认服务端强制校验且各入口一致
核查清单
核查清单
# 用自有测试账号在服务端验证（绕过前端校验，直接提交请求）
curl -s -X POST https://example.com/api/password \
-H 'Cookie: <测试账号会话>' -d 'new=123456&old=<原口令>'
curl -s -X POST https://example.com/api/password \
-H 'Cookie: <测试账号会话>' -d 'new=Company2024&old=<原口令>'
# 观察：长度不足与业务相关口令是否被拒；提示是前端还是服务端返回
# 检查其他入口：注册、管理员重置、批量导入是否执行同一策略核查项与判断
| 核查项 | 不满足时的风险 |
|---|---|
| 长度下限（建议不低于 8 位，管理账号更高） | 暴力与字典攻击成本下降 |
| 弱口令字典比对 | 业务相关口令与常见口令可直接命中 |
| 历史口令限制 | 改回旧口令使泄露口令持续有效 |
| 修改频次限制 | 可被用来试探策略边界或造成骚扰 |
策略由服务端执行才算数：前端提示与校验可被绕过，不代表策略生效，必须用请求直接验证。
锁定策略本身也要看：过于激进的锁定阈值可能被用来做拒绝服务，攻击者用错误口令即可锁住他人账号。