我应该对密码施加最大长度吗？

存储空间便宜，为什么要限制密码长度。即使您要加密密码，而不仅仅是对其进行哈希处理，64 个字符的字符串也不会比 6 个字符的字符串加密更多。

银行系统很可能覆盖了较旧的系统，因此他们只能为密码留出一定的空间。

密码被散列为 32、40、128，无论长度如何。最小长度的唯一原因是防止容易猜到的密码。最大长度没有目的。

强制性的 XKCD 解释为什么如果你强加一个最大长度，你会对你的用户造成伤害：

我认为你在这两个要点上都非常正确。如果他们按应有的方式存储哈希密码，则密码长度不会影响其数据库架构。具有开放式密码长度会引发暴力攻击者必须考虑的多一个变量。

除了糟糕的设计之外，很难看到任何限制密码长度的借口。

首先，不要以为银行有优秀的IT安全专业人员为他们工作。很多没有。

也就是说，最大密码长度毫无价值。它通常要求用户创建一个新密码（暂时搁置关于在每个站点上使用不同密码的价值的争论），这增加了他们写下密码的可能性。它还大大增加了从蛮力到社会工程的任何载体攻击的敏感性。

应该有最大长度吗？这在IT领域是一个奇怪的话题，因为较长的密码通常更难记住，因此更有可能被写下来（出于显而易见的原因，这是一个很大的禁忌）。较长的密码也往往会被遗忘，虽然不一定是安全风险，但可能导致管理麻烦、生产力损失等。认为这些问题迫在眉睫的管理员可能会对密码施加最大长度。

我个人认为，在这个具体问题上，每个用户都有自己的。如果您认为自己可以记住 40 个字符的密码，那么您就更强大了！

话虽如此，密码正迅速成为一种过时的安全模式，但智能卡和证书身份验证被证明很难甚至不可能像您所说的那样暴力破解，并且只需要将公钥存储在服务器端，私钥始终在您的卡/计算机上。

较长的密码或密码短语更难仅根据长度破解，并且比需要复杂的密码更容易记住。

可能最好选择相当长的 （10+） 最小长度，限制长度无用。

我能看到的最大密码长度的唯一好处是消除了由过长的密码引起的缓冲区溢出攻击的风险，但是有更好的方法来处理这种情况。

如果您接受来自不受信任来源的密码，则允许完全不受限制的密码长度有一个主要缺点。

发件人可能会尝试为您提供如此长的密码，从而导致其他人拒绝服务。例如，如果密码是 1GB 的数据，并且您花费了所有时间接受它，直到内存耗尽。现在假设此人向您发送此密码的次数与您愿意接受的次数相同。如果您不注意所涉及的其他参数，这可能会导致 DoS 攻击。

按照今天的标准，将上限设置为 256 个字符似乎过于慷慨。

只有 8 个字符长的密码听起来完全错误。如果应该有一个限制，那么至少 20 个字符是更好的主意。

我能想象到强制执行最大密码长度的一个原因是，如果前端必须与许多遗留系统后端接口，其中一个后端本身会强制执行最大密码长度。

另一个思考过程可能是，如果用户被迫使用短密码，他们更有可能发明随机的胡言乱语，而不是容易猜到的（被他们的朋友/家人）的流行语或昵称。当然，这种方法只有在前端强制执行混合数字/字母并拒绝包含任何字典单词的密码（包括用 l33t-speak 编写的单词）时才有效。

遗留系统（已经提到）或与供应商系统外部的接口可能需要 8 个字符的上限。这也可能是将用户从自己手中拯救出来的错误尝试。以这种方式限制它将导致系统中的 pssw0rd1、pssw0rd2 等密码过多。

我的银行也这样做。它曾经允许任何密码，而我有一个 20 个字符的密码。有一天我更改了它，瞧瞧，它给了我最多 8 个，并且删除了我旧密码中的非字母数字字符。对我来说没有任何意义。

银行的所有后端系统以前在我使用带有非字母数字的 20 个字符密码时都可以工作，因此遗留支持不可能是原因。即使是这样，他们仍然应该允许你拥有任意密码，然后进行符合遗留系统要求的哈希值。更好的是，他们应该修复遗留系统。

智能卡解决方案不适合我。我已经有太多的卡片了......我不需要其他噱头。

在密码字段中指定的最大长度应读取为安全警告。任何明智的、有安全意识的用户都必须假设最坏的情况，并期望这个网站从字面上存储你的密码（即没有哈希，正如 epochwolf 所解释的那样）。

在这种情况下：

1. 如果可能的话，避免像使用瘟疫一样使用这个网站。他们显然对安全一无所知。
2. 如果您确实必须使用该网站，请确保您的密码是唯一的 - 与您在其他地方使用的任何密码不同。

如果您正在开发一个接受密码的网站，请不要设置愚蠢的密码限制，除非您想用相同的刷子涂上柏油。

[当然，在内部，您的代码可能只将前 256/1024/2k/4k/（无论）字节视为“重要”字节，以避免处理庞大的密码。

我认为唯一应该应用的限制是 2000 个字母的限制，或者其他过高的东西，但只有在有问题的情况下才能限制数据库大小

施加一些最大密码长度的一个潜在正当理由是，哈希处理过程（由于使用了慢速哈希函数，如bcrypt）占用了太多时间;可能被滥用以对服务器执行 DOS 攻击的东西。

再说一次，服务器应配置为自动删除耗时过长的请求处理程序。所以我怀疑这会是一个很大的问题。

OWASP 身份验证备忘单现在不鼓励将最大密码长度设置为小于 128 个字符

https://www.owasp.org/index.php/Authentication_Cheat_Sheet

引用整个段落：

密码越长，字符组合越多，因此攻击者更难猜到。

密码的最小长度应由应用程序强制执行。 少于 10 个字符的密码被视为弱密码 （[1]）。 虽然最小长度强制执行可能会导致某些用户在记忆密码方面出现问题，但应用程序应鼓励他们设置密码短语（句子或单词组合），这些密码短语可能比典型密码长得多，但更容易记住。

最大密码长度不应设置得太低，因为它会阻止用户创建密码短语。通常最大长度为 128 个字符。 如果密码短语仅包含小写拉丁字符，则短于 20 个字符的密码通常被认为是弱密码。每个角色都很重要！！

确保用户键入的每个字符实际上都包含在密码中。我们已经看到系统将密码截断的长度短于用户提供的长度（例如，当他们输入 20 个字符时，在 15 个字符处被截断）。 这通常是通过将所有密码输入字段的长度设置为与最大长度密码完全相同的长度来处理的。如果您的最大密码长度很短（例如 20-30 个字符），这一点尤其重要。

密码可能不进行哈希处理的一个原因是使用的身份验证算法。例如，某些摘要算法需要服务器上密码的纯文本版本，因为身份验证机制涉及客户端和服务器对输入的密码执行相同的数学运算（通常不会每次都产生相同的输出，因为密码与随机生成的“随机数”相结合，在两台机器之间共享）。

通常，这可以得到加强，因为在某些情况下可以部分计算摘要，但并非总是如此。更好的方法是使用可逆加密存储密码 - 这意味着应用程序源需要受到保护，因为它们将包含加密密钥。

Digst 身份验证允许通过其他非加密通道进行身份验证。如果使用 SSL 或其他全通道加密，则无需使用摘要式身份验证机制，这意味着可以对密码进行哈希存储（因为密码可以通过网络安全地发送明文（对于给定的 safe 值）。

如果您接受任意大小的密码，则假设在对其进行哈希处理之前，由于性能原因，该密码被截断为窗帘长度。截断的问题在于，随着服务器性能的提高，您不能轻易增加截断前的长度，因为它的哈希值显然会有所不同。当然，您可以有一个过渡期，在过渡期中对两个长度进行哈希处理和检查，但这会占用更多资源。

除非必要，否则尽量不要施加任何限制。请注意：在许多不同的情况下，它可能而且将是必要的。处理遗留系统是这些原因之一。确保你很好地测试了非常长的密码的情况（你的系统可以处理10MB长的密码吗？您可能会遇到拒绝服务 （DoS） 问题，因为您将使用的关键定义函数 （KDF）（通常是 PBKDF2、bcrypt、scrypt）将花费大量时间和资源。现实生活中的例子：http://arstechnica.com/security/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-security/

忽略那些说不要验证长密码的人。Owasp 从字面上说 128 个字符就足够了。只是为了给足够的呼吸空间，如果你愿意，你可以再给一点，比如 300、250、500。

https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Password_Length

密码长度：密码越长，密码越长，密码长度越长，密码长度越长，密码 字符，从而使攻击者更难 猜。

...

最大密码长度不应设置得太低，因为它会阻止 用户创建密码短语。典型最大长度为 128 字符。短于 20 个字符的密码短语通常 如果它们仅由小写拉丁字符组成，则被视为弱字符。

Microsoft 根据开发人员的内部数据（您知道，来自运行计算史上最大的软件企业）为开发人员发布安全建议，您可以在线找到这些 PDF。Microsoft 表示，密码破解不仅几乎是他们最不关心的安全问题，而且：

“犯罪分子试图以各种方式伤害我们的客户，并且 我们发现绝大多数攻击都是通过网络钓鱼、恶意软件进行的 受感染的计算机，以及在第三方上重复使用密码 站点 - 这些站点都没有得到很长的密码的帮助Microsoft。

Microsoft 自己的做法是密码不能超过 16 个字符，也不能短于 8 个字符。

https://arstechnica.com/information-technology/2013/04/why-your-password-cant-have-symbols-or-be-longer-than-16-characters/#:~:text=Microsoft%20imposes%20a%20length%20limit,no%20shorter%20than%20eight%20characters。

我发现对密码的前 72 个字节使用相同的字符可以成功验证使用 和 在 PHP 中，无论前 72 个字节之后出现什么随机字符串。password_hash()password_verify()

来自 PHP 文档： https://www.php.net/manual/en/function.password-hash.php

警告：使用 PASSWORD_BCRYPT 作为算法将导致 password 参数被截断为最大长度 72 字节。

OWASP的最新更新现在建议最大长度：https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html

最大密码长度不应设置得太低，因为它会阻止用户创建密码短语。由于某些哈希算法的限制，常见的最大长度为 64 个字符，如密码存储备忘单中所述。设置最大密码长度以防止长密码拒绝服务攻击非常重要。

在 .net core 6 中，我使用 HashPasswordV3 方法，它使用具有 1000 次迭代HMACSHA512。我测试了一些密码长度，它生成了一个 86 个字符的哈希值。

因此，我在 sql server 中为 varchar（100） 设置了 PasswordHash 字段。

https://stackoverflow.com/a/72429730/9875486