[!info] related notes

• 所属 MOC: 安全 MOC
• Password Policy: Password Policy
• Password Storage: Password Storage & Verification
• Attack Model: Credential Stuffing / Spraying / Brute Force
• Online Defense: Authentication Throttling & Account Lockout

Breached Password Blocklist

一句话定义

Password Blocklist 是：

在 password creation / change 时 → 检查候选 password → 如果它属于攻击者高度可能优先尝试的集合 → reject

目标是：

阻止用户选择“看似符合格式、实际上早已进入攻击字典”的 password。

应该包含什么

NIST 当前给出的典型来源包括：

• previous breach corpuses；
• commonly used passwords；
• dictionary words；
• context-specific words；
• service name；
• username；
• username derivatives。

重点是：

攻击者实际会先猜什么。

而不是追求一个无限大的词表。

为什么 Blocklist 有价值

假设用户选择：

Company2026!

它可能满足：

• uppercase；
• lowercase；
• number；
• symbol；
• length；

但仍极其可预测。

Blocklist 可以比 composition rule 更直接回答：

attacker 是否会早期尝试这个 password？

检查完整 Password

NIST 要求对 prospective password 的完整值进行比较，而不是因为里面包含某个词就机械拒绝。

错误：

password contains “cat” → reject

这会导致：

Correct-Horse-Cat-Battery-…

这类长 passphrase 被无意义拒绝。

所以 blocklist 不应该退化成 profanity/substring filter。

Breached Password Service

一种来源是：

Have I Been Pwned Pwned Passwords

或其他 breach corpus。

部署方式可以：

• 本地下载 corpus；
• privacy-preserving prefix lookup；
• 第三方 API。

如果调用外部服务，应避免把 plaintext password 直接发送给第三方。

Context-Specific Password

通用 breach list 之外，还应考虑当前服务上下文。

例如服务叫：

BodySense

那么：

BodySense2026!

即使没有出现在大型泄漏库，也属于高度可预测 candidate。

类似：

• username；
• email local-part；
• product name；
• company name；
• obvious year suffix。

Blocklist 大小不是越大越好

NIST 特别指出：

excessively large blocklist 的增量收益有限。

因为在线 guessing 还应该被 rate limiting 控制。

真正重要的是覆盖攻击者最先尝试的高概率密码，而不是“所有单词组合”。

Blocklist ≠ Password Strength Meter

Blocklist 是 binary policy：

allowed / rejected

Strength meter 是 UX feedback：

weak / medium / strong

二者可以组合，但职责不同。

Blocklist ≠ Password Hash Database

不要把 breach corpus 与自己的 stored password hash 混淆。

Blocklist 只在：

password creation/change

检查候选秘密。

真正存储仍使用：

Password Storage & Verification。

用户反馈

命中 blocklist 时，应明确告诉用户：

这个密码过于常见或已出现在已知泄漏数据中，请选择不同密码。

不要只返回：

invalid password

否则用户可能反复做：

Password → Password1 → Password1!

这种可预测修改。

常见误区

所有字典单词都禁止

错误。重点是完整 password 的 guessability，不是 substring policing。

Blocklist 越大越安全

收益会快速递减。

有 Blocklist 就不需要 rate limit

错误。攻击者仍可尝试未列入 blocklist 的候选。

前端检查就够

错误。服务端必须再次执行 policy。

学习检查

1. Password Blocklist 防的是什么攻击行为？
2. 为什么符合复杂度规则的 password 仍可能需要被 blocklist 拒绝？
3. 为什么不应把 blocklist 做成 substring 禁词器？
4. context-specific password 是什么？
5. 为什么 blocklist 不应追求无限大？
6. 外部 breach-password API 为什么不能直接接收 plaintext password？
7. blocklist、rate limiting、password hashing 分别位于哪一层？