密码需要特殊字符 vs 密码可选特殊字符

Password required special char vs Password optional special char

为什么要求密码包含特殊字符、大写和小写字母以及数字时更安全？ allow 而不是要求这些字符会不会更安全？

假设有人想要破解密码，如果他们已经知道该密码至少包含 1 个特殊字符、1 个大小写字母和 1 个数字，这对他们来说不是更容易吗，因为这是必需的。如果密码被允许而不是必需的，而不是密码包含这些字符的可能性？

它被认为是安全的，可以抵御字典攻击等多种攻击。由于字典攻击来自具有常用词的词表。如果密码符合标准，最好在前端和后端要求这些规则并进行验证。

清单如下：

如果您遵循 OWASP 等标准，保护您的身份验证会很好。

允许而不是要求这些字符会不会更安全？

是也不是。

否：正如 Francis Al Victoriano 所说，反字典攻击很有用。

是：在理想情况下，除了密码不为空外，您不需要任何其他要求。这样，正如您所说，攻击者不会有任何关于密码可能包含什么的提示，甚至不知道他们应该在多长时间内开始暴力破解。

但在这个完美的世界中，您的用户知道他们在做什么，他们知道什么是强密码，并且每个应用程序都使用一个。可悲的是，在现实世界中，您永远不应该信任用户，因此您必须确保他们选择的密码不是 "too weak".

那么，我们是否应该强制用户在其密码中使用多个字符集？

有人说我们应该这样做，因为如果我们不这样做，用户会选择像字典单词一样的弱密码。

有人说我们不应该（比如NIST）因为：

您在密码策略中添加的限制越多，用户就越会因此而烦恼（他已经对必须使用密码这一事实感到烦恼）并且他会越多尝试绕过它并且很可能在此过程中削弱他的密码（例如，您的超级复杂密码将以 post-it 结尾，因为用户无法记住它）。
说到绕过，典型的密码策略是最少 8 个字符，至少一个大写字母、一个小写字母、一位数字和一个特殊字符。给你：P@ssw0rd。 Let's check if Have I Been Pwned thinks it is a good password，剧透警告：没有。
它阻止用户选择密码。

我对此事的看法是遵循 NIST 准则：

12 个字符的最小长度
基于最新泄露密码列表（如HIBP) and an offline strength estimator (like zxcvbn）的密码强度计，帮助用户避免弱密码
（可选）服务器端密码强度验证（基于步骤 2 的两个组成部分）如果您想确保您的用户选择了一个强密码并且您不希望或不允许他忽略密码强度计反馈。