代码审计里的口令安全：六个检查点

按 IP 与账号两个维度同时计数，才能覆盖喷洒与定向爆破两种形态

正着读代码容易漏，因为入口太多；反着找危险点，数据流只有那么几条。

先说结论

先列危险点，再回溯入口，最后确认校验与权限。

• 检查点一：所有外部入口是否都过统一校验
• 检查点二：危险函数是否集中封装
• 检查点三：校验是否只做一次、是否白名单
• 检查点四：权限判断是否在服务端
• 检查点五：错误信息是否泄露内部细节
• 检查点六：是否有兜底日志

检查点一：入口

口令喷洒是每个账号只试一两次，按账号计数的锁定策略完全看不到这种行为，日志里只有零散失败。

把入口列全：HTTP 参数、请求头、上传、消息队列、定时任务的外部输入。漏一个就白审。

检查点二：危险点

bcrypt 的 cost 每加一，单次计算时间翻倍，cost=12 大约需要 250 毫秒，这个开销要算进登录耗时。

检查点三：校验逻辑

同一个口令在多个站点复用，一处拖库之后会被直接拿去做撞库，用户侧几乎无从察觉。

看到「先替换再校验」「只在一个接口校验」这两种写法，基本可以直接标红。

这个问题的几个审计细节

实际代码里最容易漏的几处：

• 按 IP 与账号两个维度同时计数，才能覆盖喷洒与定向爆破两种形态

检查点四到六

按 IP 与账号两个维度同时计数，才能覆盖喷洒与定向爆破两种形态。

越权是审计里性价比最高的方向：少一行判断，就是一个中高危。错误信息要统一，日志要记入口摘要。

再补充几点

这几条不改变结论，但会改变你评估风险时的顺序。

• 强制 90 天换一次密码已被 NIST 明确不推荐，它只会催生 Password1! 这类规律
• 把登录失败提示统一成「账号或密码错误」，可以避免账号是否存在被枚举
• 只在网页登录接口限流，忘了 API 与 VPN 入口
• 把口令在前端做哈希，传输层本来就有 TLS
• 用复杂度代替长度，用户写成 Abc123! 反而更好猜

审计的产出不是「找到几个洞」，是「知道这类洞在哪个模式里反复出现」。