[!info] related notes

• 所属 MOC: 安全 MOC
• Password Storage: Password Storage & Verification
• Blocklist: Breached Password Blocklist
• Online Defense: Authentication Throttling & Account Lockout
• Attack Model: Brute Force、Password Spraying 与 Credential Stuffing
• MFA: Password 与 MFA 的安全边界

Password Policy

一句话模型

现代 Password Policy 的目标不是：

让密码看起来复杂。

而是：

让用户更难选择攻击者优先尝试的密码，同时不破坏 password manager、passphrase 和长期可用性。

核心组合：

length

• blocklist
• no silent truncation
• password-manager friendly UX
• rate limiting
• compromise-driven change

长度

NIST SP 800-63B-4 当前要求：

• Password 作为 single-factor authentication：minimum 15 characters；
• Password 只作为 multi-factor authentication 中的一个因素：minimum 8 characters；
• 应支持至少 64 characters 的 maximum length；
• Unicode code point 应按一个 character 计数。

因此：

8 characters everywhere

已经不是稳定的通用政策模型。

不要强制 Composition Rules

旧策略：

• 至少一个大写；
• 至少一个小写；
• 至少一个数字；
• 至少一个符号；

会诱导可预测变体，例如：

Password1!

攻击者早已把这些 pattern 放进 cracking rule。

所以现代策略不应要求这种字符组合。

允许：

• spaces；
• printable ASCII；
• Unicode；

更利于长 passphrase 和 password manager。

不要静默截断

如果系统只验证 password 前 N bytes：

user thinks: very-long-password-X

server actually verifies: very-long-pass…

就会产生多个表面不同 password 实际等价的问题。

因此：

verifier 应验证完整提交的 password。

如果底层 bcrypt 等 legacy scheme 有 72-byte 边界，应在产品和迁移策略中显式处理，而不是静默截断。

Blocklist

创建或修改 password 时，应检查：

• commonly used passwords；
• breached passwords；
• dictionary words；
• service-specific predictable values；
• username/email-derived values。

如果命中：

reject → explain why → ask user to choose another secret

详见 Breached Password Blocklist。

不要周期强制改密

旧策略：

every 30/60/90 days → force password reset

会诱导：

Password1 → Password2 → Password3

现代策略：

没有 compromise evidence 时，不做任意周期 rotation。

应在：

• credential breach；
• account takeover evidence；
• password disclosure；
• verifier migration requiring reset；

等事件后强制变更。

Password Manager Friendly

登录/注册 UI 应：

• 允许 autofill；
• 允许 paste；
• 使用标准 password input；
• 支持合理长的 password；
• 不阻止 password manager；
• 可提供 show password toggle。

禁止 paste 往往降低安全，因为用户更倾向选择短、易输、重复的 password。

Password Strength Meter

Strength meter 可以作为辅助反馈。

但不要把：

entropy score → security proof

因为 user-chosen password 的真实 guessability 很难用简单字符集公式估算。

更好的 meter 应考虑：

• common patterns；
• dictionary；
• leaked password；
• repeated sequence；
• user context。

Password Policy 与 Password Storage

Policy 负责：

用户允许选择什么 password。

Password Storage 负责：

server 怎样保存 verifier。

两者是不同层：

Password Policy → input quality / usability

Password Hashing → database breach / offline guessing resistance

详见 Password Storage & Verification。

Password Policy 与 Rate Limiting

再长的 password 也不能替代 online throttling。

攻击者仍可以：

• credential stuffing；
• password spraying；
• automated guessing。

因此 verifier 必须限制失败认证尝试。

详见 Authentication Throttling & Account Lockout。

Password Policy 与 MFA

MFA 可以降低 password 单点失守风险。

但：

• MFA 不会让弱 password 本身变强；
• 密码仍可能用于 recovery；
• 某些 MFA 可被 phishing；
• MFA reset flow 可能成为最弱点。

详见 Password 与 MFA 的安全边界。

常见错误

强制大写小写数字符号

现代主流 guidance 已不再推荐。

每 90 天改密码

没有 compromise evidence 时，通常会制造更可预测的密码。

禁止 paste

会损害 password manager 使用。

最大长度 16/20

会直接阻碍 passphrase/password manager。

用前端 strength meter 代替服务端 policy

前端提示可以被绕过，真正 policy 必须服务端执行。

学习检查

1. 为什么现代 Password Policy 更强调长度而不是字符组合？
2. single-factor 与 MFA 场景的 minimum length 为什么不同？
3. 为什么不能静默截断 password？
4. 周期强制改密为什么可能降低实际安全性？
5. password blocklist 与 password hashing 分别防什么？
6. 为什么应该允许 paste/autofill？
7. MFA 为什么不能替代 Password Policy？
8. 给一个旧“8 位+大小写+数字+90天改密”策略，重构成现代版本。