我应该在密码上加上最大长度吗？

Question

我可以理解，在密码上施加最小长度非常有意义（为了节省用户），但我的银行要求密码长度在6到8个字符之间，并且我开始想知道......

• 这不会让蛮力攻击更容易吗？ （坏）
• 这是否意味着我的密码未加密存储？ （坏）

如果某人（希望）有一些优秀的IT安全专业人员为他们工作，那么我是否应该考虑做类似的事情？这有什么优点/缺点？

Answer 1

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

强制性XKCD解释了如果您施加最大长度，为什么您的用户会受到损害：

Answer 2

密码字段中指定的最大长度应读作安全警告： 任何明智的，注重安全的用户必须承担最坏的情况，并期望这个网站按字面意思存储您的密码（即没有哈希，如epochwolf所解释的那样）。

就是这样： （a）尽可能避免像瘟疫一样使用这个网站[他们显然知道关于安全的问题] （b）如果您必须使用该网站，请确保您的密码是唯一的 - 与您在其他地方使用的密码不同。

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

[内部，当然，您的代码可能只将第一个256/1028 / 2k / 4k（无论如何）字节视为“重要”，以避免对猛犸密码进行处理。]

Answer 3

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

发件人可能会尝试给您这么长的密码，导致其他人拒绝服务。例如，如果密码是1GB的数据，那么您将花费所有时间接受它，直到内存不足为止。现在假设此人向您发送此密码的次数是您愿意接受的次数。如果您对所涉及的其他参数不小心，可能会导致DoS攻击。

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

Answer 4

首先，不要假设银行拥有为他们工作的优秀IT安全专业人员。 Plenty don't

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

Answer 5

OWASP身份验证备忘单

现在不鼓励最大密码长度限制

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

引用整段：

  

较长的密码会提供更多的字符组合，从而使攻击者更难以猜测。

     

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

     

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

     

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

Answer 6

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

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

Answer 7

施加一些最大密码长度的一个可能有效的理由是对其进行散列的过程（由于使用慢速散列函数，例如bcrypt）占用了太多时间;为了对服务器执行DOS攻击，可能会被滥用的东西。

然后，服务器应该配置为自动删除花费太长时间的请求处理程序。所以我怀疑这会是一个很大的问题。

Answer 8

我认为你在两个要点上都是对的。如果他们正在存储密码哈希值，那么密码长度不会影响他们的数据库架构。具有开放式密码长度会引发蛮力攻击者必须考虑的另一个变量。

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

Answer 9

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

Answer 10

忽略那些不会验证长密码的人。 Owasp字面上说128个字符就足够了。只要给予足够的呼吸空间，如果您愿意，可以多说300,250,500。

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

  

密码长度更长的密码提供更好的组合   角色，因此使攻击者更难以   猜测。

     

...

     

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

Answer 11

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

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

Answer 12

如果您接受任意大小的密码，那么可以假设它在被散列之前由于性能原因而被截断为窗帘长度。截断的问题是随着您的服务器性能随着时间的推移而增加，您无法在截断之前轻松增加长度，因为它的哈希显然会有所不同。当然，您可以有一个过渡期，其中两个长度都经过散列和检查，但这会占用更多资源。

Answer 13

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

银行的所有后端系统都在我使用带有非字数字的20字符密码之前工作，所以传统支持不是原因。即使它是，它们仍然应该允许您拥有任意密码，然后制作符合遗留系统要求的哈希。更好的是，他们应该修复遗留系统。

智能卡解决方案不适合我。我已经有太多卡了......我不需要另外一个噱头。

Answer 14

传统系统（已提及）或供应商系统外部的接口可能需要8个字符的上限。将用户从自己身上拯救出来也可能是一种错误的尝试。以这种方式限制它将导致系统中有太多pssw0rd1，pssw0rd2等密码。

Answer 15

密码可能未被散列的一个原因是使用的验证算法。例如，某些digest algorithms在服务器上需要明文版密码，因为身份验证机制涉及客户端和服务器对输入的密码执行相同的数学运算（通常每次都不会产生相同的输出）因为密码与随机生成的'nonce'结合，后者在两台机器之间共享。）

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

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

Answer 16

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

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

Answer 17

除非必要，否则尽量不要施加任何限制。请注意：在许多不同的情况下，它可能并且将是必要的。处理遗留系统是其中一个原因。确保你很好地测试了很长的密码（你的系统可以处理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/

Answer 18

是否应该有最大长度？这在IT中是一个奇怪的主题，因为较长的密码通常难以记住，因此更容易被写下来（由于显而易见的原因，这是一个很大的禁忌）。更长的密码也往往会被遗忘更多，虽然不一定是安全风险，但可能导致行政麻烦，生产力下降等。相信这些问题迫在眉睫的管理员可能会对密码施加最大限度的长度。

我个人认为这个具体问题，对每个用户都是自己的。如果你认为你能记住一个40个字符的密码，那么你就更有权力了！

尽管如此，密码很快就会成为一种过时的安全模式，智能卡和证书身份验证很难被证明是不可能的，因为你说的是​​一个问题，只需要一个公钥存储在服务器端随时使用卡/计算机上的私钥。

Answer 19

我认为应该应用的唯一限制就像是2000字母限制，或者其他一些非常高的限制，但仅限于数据库大小（如果这是一个问题）

Answer 20

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