我应该对密码设置最大长度吗？

我可以理解，对密码施加最小长度是很有意义的（为了使用户免于自己的攻击），但是我的银行要求密码长度必须介于6到8个字符之间，我开始怀疑...

• 这难道不只是使暴力攻击更容易吗？（坏）
• 这是否意味着我的密码未加密存储？（坏）

如果有人（希望）有一些出色的IT安全专业人员正在为他们强加最大密码长度，我是否应该考虑做类似的事情？这有什么优点/缺点？

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

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

在密码字段上指定的最大长度应作为“ 安全警告”阅读。任何明智，注重安全的用户都必须承担最糟糕的后果，并希望该站点按字面意义存储您的密码（即，如epochwolf所述，不进行哈希处理）。

在这种情况下：

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

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

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

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

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

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

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

也就是说，最大密码长度毫无意义。它通常要求用户创建一个新密码（有关暂时在每个站点上使用不同密码的价值的争论），这增加了他们将其写下来的可能性。从蛮力到社会工程学的任何媒介，也极大地增加了受到攻击的可能性。

OWASP身份验证备忘单现在建议不要将最大密码长度设置为少于128个字符

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

引用整个段落：

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

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

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

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

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

另一个思考过程可能是，如果用户被迫使用短密码，那么他们比轻易猜出（由他们的朋友/家人）流行的短语或昵称更有可能发明乱码。这种方法当然仅在前端强制使用混合数字/字母并拒绝具有任何词典单词（包括用33t讲的单词）的密码时才有效。

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

然后，服务器应再次配置为自动删除耗时太长的请求处理程序。因此，我怀疑这将是一个很大的问题。

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

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

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

忽略人们说不要验证长密码的信息。Owasp的字面意思是128个字符就足够了。只是给了足够的呼吸空间，如果您愿意，可以多说300、250、500。

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

密码长度较长的密码提供了更多的字符组合，因此使攻击者更难以猜测。

...

密码的最大长度不应设置得太短，因为它将阻止用户创建密码短语。典型的最大长度是128个字符。如果密码短语仅包含小写拉丁字符，则通常少于20个字符。

存储价格便宜，为什么要限制密码长度。即使您要加密密码而不是仅对其进行散列，加密64个字符串也不会花费超过6个字符串。

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

我的银行也这样做。它曾经允许使用任何密码，而我只有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/

应该有最大长度吗？这在IT领域是一个很好奇的话题，因为较长的密码通常更难记，因此更容易被写下来（出于明显的原因，BIG禁止使用）。较长的密码也往往会被遗忘，这虽然不一定带来安全风险，但可能导致管理麻烦，生产力下降等。管理员认为这些问题很紧迫，很可能会给密码设置最大长度。

我个人相信在这个特定的问题上，对每个用户来说都是自己的。如果您认为自己可以记住40个字符的密码，那么，强大的功能就给您了！

话虽这么说，但是密码正迅速成为一种过时的安全性模式，正如您所说的那样，智能卡和证书身份验证非常困难，甚至无法进行暴力破解，并且只有公共密钥需要与私有密钥一起存储在服务器端。始终在您的卡/计算机上输入密钥。

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

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

传统系统（已经提到过）或与外部厂商系统的接口可能需要8个字符的上限。将用户从自己手中救出来也可能是一种误导的尝试。以这种方式进行限制会导致系统中出现过多的pssw0rd1，pssw0rd2等密码。

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

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

Digst auth可以通过其他未加密的通道进行身份验证。如果使用SSL或其他某种全通道加密，则无需使用摘要身份验证机制，这意味着可以将密码存储为散列（因为可以安全地通过网络以明文形式发送密码（给定的安全值）。

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

我认为应该应用的唯一限制是2000个字母限制，或者其他非常高的限制，但是仅在存在问题时才限制数据库大小