口令安全到底是什么：从数据流看它的边界

强制 90 天换一次密码已被 NIST 明确不推荐，它只会催生 Password1! 这类规律

理解它的关键是画出三条线：入口、信任边界、危险点。

先说结论

漏洞的本质是「不可信数据到达了危险点」，防御的本质是「在中间加一道能正确判断的关卡」。

• 入口：数据从哪来，谁都能改吗
• 边界：跨边界时有没有做类型与格式判断
• 危险点：拼接、解析、执行、反序列化
• 前置条件：需要什么权限、什么配置
• 影响面：能读到什么、能改到什么

数据流：从入口到危险点

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

信任边界在哪

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

边界两侧的数据可信度不同，所有校验都应该发生在边界上，而不是散落在业务代码里。

这个问题的几个关键事实

决定它「是理论还是现实」的几条：

• 口令喷洒是每个账号只试一两次，按账号计数的锁定策略完全看不到这种行为，日志里只有零散失败
• 按 IP 与账号两个维度同时计数，才能覆盖喷洒与定向爆破两种形态

影响面怎么判

评估危害时先问：需要什么身份、需要开什么配置、能不能碰到内网。三个问题的答案决定了它是「低危」还是「要连夜修」。

为什么总是修不干净

只在网页登录接口限流，忘了 API 与 VPN 入口

把口令在前端做哈希，传输层本来就有 TLS

根因通常是「同一个入口有多个解析器」，修了一个，另一个还通。

再补充几点

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

• 强制 90 天换一次密码已被 NIST 明确不推荐，它只会催生 Password1! 这类规律
• 把登录失败提示统一成「账号或密码错误」，可以避免账号是否存在被枚举
• 用复杂度代替长度，用户写成 Abc123! 反而更好猜

理解数据流，比背 payload 有用得多。