网页应用密码限制策略调研

一、调研范围与主要信源

本次调研聚焦「网页应用应如何设置用户密码策略」这一问题，重点参考了权威标准、安全社区共识和可用性研究三类来源：

• 标准：NIST SP 800-63B（最新修订版，2025 年 8 月公开草案及 2024 年正式版）¹
• 实践指南：OWASP Authentication Cheat Sheet²
• UX 研究：Baymard Institute 关于电商网站密码要求的可用性测试³
• 一线经验：Authgear、Passwork、Security StackExchange 等社区与厂商文章⁴

本节注释

1. NIST SP 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management, Sec. 3.1.1 / Appendix A. ↩
2. OWASP, Authentication Cheat Sheet, "Implement Proper Password Strength Controls". ↩
3. Baymard Institute, "Avoid Unnecessarily Complex Password-Creation Requirements (82% Don’t)", 2022-11-29. ↩
4. Authgear, "Why Your Password Complexity Policy Is Making You Less Secure"; Security StackExchange, "What password policy should a typical web app have?". ↩

二、服务限制密码的原因

网站对密码设限，本质上是把一部分安全责任转嫁给用户，同时降低平台自身的风险。常见动机可归纳为四类：

1. 抵抗自动化攻击

更长的字符集能显著拖慢离线哈希破解（如 hashcat）的速度。若数据库泄露，一个 8 位纯数字密码可在秒级破解，而 15 位以上的随机或短语密码则让攻击者望而却步。

2. 满足合规与审计

等保、PCI DSS、ISO 27001、GDPR 等框架对身份鉴权有明确要求。企业在安全审计时，需要一份「看起来合理」的密码策略作为尽职证据。

3. 降低用户账户接管风险

禁止常见弱口令（如 123456、password）和已泄露密码，可直接阻断大量撞库与凭证填充攻击。

4. 减少客服与运营成本

过于宽松导致频繁被盗号、重置密码和投诉，会消耗大量客服资源。平台希望用户在注册时一次性设置「足够好」的密码。

三、常见的限制等级

不同场景下的密码策略大致可分为以下四级。注意：这里「严格」不等于「安全」，现代观点反而认为过度严格常常适得其反。

一位 Security StackExchange 上的高票回答指出，对于典型 Web 应用，真正重要的不是无限提高复杂度，而是阻止高速暴力破解、使用现代哈希存储和检查已泄露密码。

四、NIST / OWASP 现行建议

近几年的权威标准已经明显转向「长度优先、复杂度让位」。核心结论如下：

Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.

—— NIST SP 800-63B Sec. 3.1.1.2

• 最小长度：单因子认证至少 15 个字符；若启用了 MFA，可降至 8 个字符¹。
• 最大长度：至少支持 64 个字符，以便使用密码短语（passphrase）²。
• 字符集：允许所有可打印 ASCII、空格及 Unicode，不应限制或强制特定字符类型。
• 黑名单：必须对照常见字典词、上下文相关词（站点名、用户名）和已泄露密码库进行校验。
• 更换周期：不应强制定期更换；仅在确认泄露后要求修改。
• 传输与存储：全程 TLS；使用 Argon2id / bcrypt / scrypt 加盐哈希。
• 辅助措施：限流、CAPTCHA、MFA、密码管理器友好、强度条、Passkeys。

OWASP 进一步建议前端使用 zxcvbn 等库做实时强度反馈，而不是简单检查字符类型。

本节注释

1. NIST SP 800-63B Sec. 3.1.1.2: "Verifiers and CSPs SHALL require passwords that are used as a single-factor authentication mechanism to be a minimum of 15 characters in length." ↩
2. OWASP Authentication Cheat Sheet: "Maximum password length should be at least 64 characters to allow passphrases." ↩

五、过度复杂的副作用

Baymard Institute 的测试发现，82% 的电商网站设置了「不必要的复杂密码要求」。其后果不是注册时的立即放弃，而是后续登录时的记忆失败、重置流程和购物车流失——部分站点的结账放弃率高达 19% solely because of password reset issues¹。

Authgear 总结了几种典型的反作用行为：

• 用户把密码写在便签、手机备忘录或邮件草稿里；
• 生成一套「万能复杂密码」到处复用；
• 按季节/年份递增，如 Spring2024! → Summer2024!；
• 把简单词套用规则，如 password → Password1!，而这些正是破解字典的首选。

NIST 在 Appendix A 中明确指出：过度复杂的密码更难记忆，更可能被不安全地记录；黑名单、限速和哈希存储才是对抗现代暴力破解更有效的手段²。

本节注释

1. Baymard Institute, "Avoid Unnecessarily Complex Password-Creation Requirements". ↩
2. NIST SP 800-63B Appendix A, "Complexity": "Highly complex passwords introduce a new potential vulnerability: they are less likely to be memorable and more likely to be written down or stored electronically in an unsafe manner." ↩

六、对你那种「四类字符 + 数字不递增」模式的评估

你描述的策略是：数字、大小写字母、特殊符号必须全部包含，且数字部分不能有递增或简单重复。这种模式算得上严格，但对一般网页应用并无必要，甚至可能帮倒忙。

为什么过于严格

• 违反 NIST/OWASP 核心建议。两者都明确反对强制字符类型组合。
• 安全收益有限。真正提升抗破解能力的是长度和熵，而不是「必须有一个 @ 符号」。Password123! 完全符合四类字符要求，却仍是最常见的弱口令之一。
• 「数字不递增/不重复」作用可疑。这条规则主要防范在线猜测中的直观弱模式，但在线攻击本应由限速和异常检测解决；对离线哈希破解而言，知晓这一规则反而会缩小攻击者的搜索空间。
• 可用性与兼容性代价大。不同键盘布局、移动端、旧系统对特殊字符支持不一致；用户容易卡在注册页。

何时可能适用

只有在明确合规要求或极高安全场景（如金融核心系统、政府内网）下，才考虑在 15+ 位长度、MFA、黑名单等基础之上附加字符类型限制。即便如此，仍应优先推广 Passkeys 或硬件密钥，而不是把复杂度转嫁给用户。

七、给网页应用的具体建议

基于以上调研，如果你的网页应用面向普通用户、没有特殊合规强制，推荐按以下优先级配置：

一句话结论：把力气花在长度、黑名单、限速、MFA 和密码管理器友好上，而不是复杂的字符规则。

八、参考文章

1. NIST SP 800-63B (latest): https://pages.nist.gov/800-63-4/sp800-63b.html
2. OWASP Authentication Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
3. Baymard Institute — Avoid Unnecessarily Complex Password-Creation Requirements: https://baymard.com/blog/password-requirements-and-password-reset
4. Authgear — Why Your Password Complexity Policy Is Making You Less Secure: https://www.authgear.com/post/why-your-password-complexity-policy-is-making-you-less-secure-and-what-to-do-instead
5. Security StackExchange — What password policy should a typical web app have?: https://security.stackexchange.com/questions/205394/what-password-policy-should-a-typical-web-app-have
6. LoginRadius — Password Security Best Practices & Compliance: https://www.loginradius.com/blog/engineering/password-security-best-practices-compliance
7. Passwork — Guide to creating and enforcing secure password policies: https://passwork.pro/blog/password-policy
8. Linford Co. — NIST Password Policy Guidelines 2024: https://linfordco.com/blog/nist-password-policy-guidelines