我应该对密码施加最大长度吗？
我可以理解对密码施加最小长度很有意义（以保护用户免受他们自己的伤害），但我的银行要求密码长度在 6 到 8 个字符之间，我开始怀疑......
这不是让暴力攻击更容易吗？ （坏的）
这是否意味着我的密码未加密存储？ （坏的）
如果有人（希望）有一些优秀的 IT 安全专业人员为他们工作，他们规定了最大密码长度，我应该考虑做类似的事情吗？这有什么优点/缺点？
密码散列为 32、40、128，无论长度如何。最小长度的唯一原因是为了防止容易猜到密码。没有最大长度的目的。
强制性的 XKCD 解释了如果您施加最大长度，为什么会对您的用户造成伤害：
https://imgs.xkcd.com/comics/password_strength.png
密码字段上指定的最大长度应被视为安全警告。任何明智的、有安全意识的用户都必须做最坏的打算，并期望该站点按字面意思存储您的密码（即没有散列，正如 epochwolf 所解释的那样）。
在这种情况下：
尽可能避免像瘟疫一样使用这个网站。他们显然对安全一无所知。如果您确实必须使用该网站，请确保您的密码是唯一的 - 与您在其他地方使用的任何密码不同。
如果您正在开发一个接受密码的网站，请不要设置愚蠢的密码限制，除非您想用相同的刷子涂上焦油。
[当然，在内部，您的代码可能仅将前 256/1024/2k/4k/（无论）字节视为“重要”字节，以避免处理庞大的密码。]
如果您接受来自不受信任来源的密码，则允许完全无限制的密码长度是一个主要缺点。
发件人可能会尝试向您提供如此长的密码，从而导致拒绝为其他人提供服务。例如，如果密码是 1GB 的数据，而您一直在接受它，直到内存不足。现在假设此人向您发送此密码的次数与您愿意接受的次数一样多。如果您不注意所涉及的其他参数，这可能会导致 DoS 攻击。
按照今天的标准，将上限设置为 256 个字符似乎过于慷慨。
首先，不要假设银行有优秀的 IT 安全专业人员为他们工作。 Plenty don't。
也就是说，最大密码长度毫无价值。它通常要求用户创建一个新密码（关于在每个站点上使用不同密码的价值的争论暂时搁置一旁），这增加了他们将其写下来的可能性。它还极大地增加了攻击的敏感性，从蛮力到社会工程的任何载体。
OWASP Authentication Cheat Sheet 现在不鼓励将最大密码长度设置为小于 128 个字符
https://www.owasp.org/index.php/Authentication_Cheat_Sheet
引用整段：
较长的密码提供了更多的字符组合，因此使攻击者更难猜测。应用程序应强制执行密码的最小长度。少于 10 个字符的密码被认为是弱密码 ([1])。虽然强制最小长度可能会导致某些用户在记忆密码方面出现问题，但应用程序应鼓励他们设置比典型密码长得多但更容易记住的密码短语（句子或单词组合）。最大密码长度不应设置得太低，因为它会阻止用户创建密码短语。典型的最大长度为 128 个字符。如果密码短语仅包含小写拉丁字符，则通常认为少于 20 个字符的密码短语很弱。每个角色都很重要！！确保用户输入的每个字符都包含在密码中。我们已经看到系统将密码截断长度比用户提供的长度短（例如，当他们输入 20 时截断为 15 个字符）。这通常通过将所有密码输入字段的长度设置为与最大长度密码完全相同的长度来处理。如果您的最大密码长度很短，例如 20-30 个字符，这一点尤其重要。
我可以想象强制执行最大密码长度的一个原因是前端是否必须与许多遗留系统后端接口，其中一个后端本身强制执行最大密码长度。
另一个思考过程可能是，如果用户被迫使用短密码，他们更有可能发明随机的胡言乱语，而不是容易猜到（由他们的朋友/家人）的流行语或昵称。这种方法当然只有在前端强制混合数字/字母并拒绝包含任何字典单词的密码时才有效，包括用 l33t-speak 编写的单词。
强加某个最大密码长度的一个潜在有效原因是对其进行哈希处理（由于使用了诸如 bcrypt 之类的慢哈希函数）占用了太多时间；可能被滥用以对服务器执行 DOS 攻击的东西。
再说一次，服务器应该被配置为自动丢弃需要太长时间的请求处理程序。所以我怀疑这会是一个很大的问题。
我认为你在两个要点上都非常正确。如果他们按照他们应该的方式存储散列密码，那么密码长度不会影响他们的数据库架构。具有开放式密码长度会引发暴力攻击者必须考虑的另一个变量。
除了糟糕的设计之外，很难找到任何限制密码长度的借口。
我可以看到最大密码长度的唯一好处是消除由过长密码引起的缓冲区溢出攻击的风险，但是有更好的方法来处理这种情况。
忽略那些说不要验证长密码的人。 Owasp 从字面上说 128 个字符就足够了。只是为了提供足够的呼吸空间，如果您愿意，您可以多说 300、250、500。
https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Password_Length
密码长度 较长的密码提供了更多的字符组合，因此使攻击者更难猜测。 ... 最大密码长度不应设置得太低，因为它会阻止用户创建密码。典型的最大长度为 128 个字符。如果密码短语仅包含小写拉丁字符，则通常认为少于 20 个字符的密码短语很弱。
我的银行也是这样。它曾经允许任何密码，我有一个 20 个字符的密码。有一天我改变了它，你瞧，它给了我最多 8 个，并删除了我旧密码中的非字母数字字符。对我没有任何意义。
在我使用非字母数字的 20 字符密码之前，银行的所有后端系统都可以正常工作，因此不可能是遗留支持。即使是这样，它们仍然应该允许您拥有任意密码，然后制作符合遗留系统要求的哈希值。更好的是，他们应该修复遗留系统。
智能卡解决方案不适合我。我已经有太多卡了……我不需要其他噱头。
如果您接受任意大小的密码，那么人们会假设出于性能原因它在被散列之前被截断为窗帘长度。截断的问题在于，随着您的服务器性能随着时间的推移而增加，您不能轻易地增加截断之前的长度，因为它的散列显然会有所不同。当然，您可以有一个过渡期，其中两个长度都被散列和检查，但这会使用更多资源。
除非必要，否则尽量不要施加任何限制。请注意：在许多不同的情况下，它可能而且将是必要的。处理遗留系统是这些原因之一。确保你很好地测试了很长密码的情况（你的系统可以处理 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/
存储便宜，为什么要限制密码长度。即使您要加密密码而不是仅对其进行散列处理，64 个字符的字符串也不会超过 6 个字符的字符串来加密。
银行系统可能会覆盖旧系统，因此他们只能为密码留出一定的空间。
应该有一个最大长度吗？这是 IT 领域的一个奇怪话题，因为较长的密码通常更难记住，因此更有可能被写下来（出于显而易见的原因，这是一个很大的禁忌）。较长的密码也容易被遗忘，这虽然不一定是安全风险，但可能导致管理麻烦、生产力下降等。认为这些问题紧迫的管理员可能会对密码施加最大长度。
我个人相信在这个具体问题上，对每个用户自己来说。如果您认为您可以记住 40 个字符的密码，那么您的力量就更大了！
话虽如此，密码正在迅速成为一种过时的安全模式，智能卡和证书身份验证证明很难甚至不可能暴力破解，因为您所说的是一个问题，并且只需要将公钥与私有密钥一起存储在服务器端始终在您的卡/计算机上输入密码。
较长的密码或密码短语更难仅根据长度来破解，并且比需要复杂的密码更容易记住。可能最好选择相当长（10+）的最小长度，限制长度无用。
旧系统（已经提到）或与外部供应商系统的接口可能需要 8 个字符的上限。这也可能是一种将用户从自己手中拯救出来的错误尝试。以这种方式限制它会导致系统中的 pssw0rd1、pssw0rd2 等密码过多。
密码可能不会被散列的一个原因是所使用的身份验证算法。例如，某些 digest algorithms 需要在服务器上提供明文版本的密码，因为身份验证机制涉及客户端和服务器对输入的密码执行相同的数学运算（通常不会每次都产生与密码与随机生成的“nonce”相结合，在两台机器之间共享）。
通常这可以得到加强，因为在某些情况下可以部分计算摘要，但并非总是如此。更好的方法是使用可逆加密存储密码 - 这意味着应用程序源需要受到保护，因为它们将包含加密密钥。
Digst auth 允许通过其他非加密通道进行身份验证。如果使用 SSL 或其他一些全通道加密，则无需使用摘要身份验证机制，这意味着密码可以存储为散列（因为密码可以通过网络安全地发送明文（对于给定的安全值）。
Microsoft 根据开发人员的内部数据（您知道，来自运行计算史上最大的软件企业）为开发人员发布安全建议，您可以在线找到这些 PDF。微软表示，密码破解不仅是他们最不关心的安全问题，而且：
“犯罪分子试图以各种方式伤害我们的客户，我们发现绝大多数攻击是通过网络钓鱼、受恶意软件感染的机器以及在第三方网站上重复使用密码进行的——很长的密码都没有帮助。” -微软
微软自己的做法是密码不能超过 16 个字符，不能短于 8 个字符。
我发现在密码的前 72 个字节中使用相同的字符可以在 PHP 中使用 password_hash() 和 password_verify() 成功验证，无论前 72 个字节之后是什么随机字符串。
来自 PHP 文档：https://www.php.net/manual/en/function.password-hash.php
注意：使用 PASSWORD_BCRYPT 作为算法，将导致密码参数被截断为最大 72 字节长度。
只有 8 个字符长的密码听起来完全是错误的。如果应该有一个限制，那么至少 20 个字符是更好的主意。
我认为应该应用的唯一限制是 2000 个字母的限制，或者其他高得离谱的限制，但如果这是一个问题，只能限制数据库大小
