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

存储很便宜，为什么要限制密码长度。即使你正在加密密码，而不是仅仅哈希它一个64个字符的字符串不会采取多于6个字符的字符串加密。

银行系统可能覆盖了一个旧系统，所以他们只能为密码留出一定的空间。

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

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

我觉得你两点都说对了。如果他们像应该的那样存储密码散列，那么密码长度不会影响他们的 DB 模式。使用开放式密码长度会引入另一个变量，而暴力攻击者必须考虑这个变量。

除了糟糕的设计之外，很难找到任何理由来限制密码长度。

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

也就是说，最大密码长度是没有价值的。它通常要求用户创建一个新的密码(暂且不论在每个网站上使用不同密码的价值) ，这增加了他们将密码写下来的可能性。它还大大增加了攻击的易感性，从任何载体的暴力到社会工程。

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

我个人认为对于这个具体的问题，每个用户都有自己的看法。如果你认为你可以记住一个40个字符的密码，那么所有的权力都给你！

尽管如此，密码正在迅速成为一种过时的安全模式，智能卡和证书认证证明非常难以不可能暴力，因为你说是一个问题，只有一个公钥需要存储在服务器端与私人密钥在您的卡/计算机任何时候。

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

也许最好是去一个相当长(10 +)的最小长度，限制长度无用。

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

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

发送者可能会尝试给你一个很长的密码，这会导致其他人的分布式拒绝服务攻击。例如，如果密码是1GB 的数据，并且您花费了所有的时间来接受它，直到您耗尽了内存。现在假设这个人给你发送了这个密码，只要你愿意接受。如果你不小心其他参数，这可能会导致拒绝服务攻击。

以今天的标准来看，将上限设置为256个字符似乎过于慷慨了。

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

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

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

遗留系统(前面已经提到过)或外部供应商系统的接口可能需要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个字符，那么这一点尤其重要。

不对密码进行哈希处理的一个原因是所使用的身份验证算法。例如，一些 摘要算法需要在服务器上输入明文版本的密码，因为身份验证机制涉及客户端和服务器对输入的密码执行相同的数学运算(当密码与随机生成的“ nonce”(两台机器共享)组合时，通常不会产生相同的输出)。

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

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

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

除非必要，不要强加任何限制。请注意: 在许多不同的情况下，这可能也将是必要的。处理遗留系统是其中一个原因。确保您很好地测试了非常长的密码情况(您的系统能够处理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个字符的密码短语通常是 如果它们仅由小写拉丁字符组成，则被认为是弱字符。