我应该在密码上施加最大长度吗？
我可以理解，在密码上加上一个最小长度是很有意义的（为了节省用户的时间），但是我的银行要求密码长度在6到8个字符之间，我开始怀疑…
- 难道这不会让暴力攻击更容易吗？ （坏）
- 这是否意味着我的密码未encryption存储？ （坏）
如果有人（希望）为他们工作的一些优秀的IT安全专家正在施加最大的密码长度，我应该考虑做类似的事情吗？ 这有什么优点/缺点？
密码被散列到32,40和128，无论长度。 最小长度的唯一原因是为了防止轻松猜测密码。 没有最大长度的目的。
强制性的XKCD解释了为什么你做你的用户损害，如果你施加一个最大长度：
在密码字段中指定的最大长度应该被看作是一个安全警告 ：任何明智的，有安全意识的用户必须承担最坏的情况，并期望这个网站按照字面意思存储你的密码（即不被散列，如epochwolf所解释的那样）。
在这种情况下是这样的：（a）尽可能避免像使用鼠疫这样的网站[他们显然知道有关安全的坚定]（b）如果您必须使用网站，请确保您的密码是唯一的 – 不像您在其他地方使用的任何密码。
如果您正在开发一个接受密码的网站，请不要input一个愚蠢的密码限制，除非您想用相同的笔刷进行涂抹。
[当然，在内部，你的代码只能把第一个256/1028 / 2k / 4k（不pipe）的字节视为“重要的”，以避免使用庞大的密码。]
如果您接受来自不受信任的来源的密码，允许完全无限的密码长度有一个主要的缺点。
发件人可能会尝试给你这么长的密码，导致其他人拒绝服务。 例如，如果密码是1GB的数据，并且您花费所有的时间来接受它，直到内存不足。 现在假设这个人向你发送这个密码的次数是你愿意接受的次数。 如果你不小心其他参数，这可能会导致DoS攻击。
按照今天的标准来设定上限为256个字符似乎过于慷慨。
首先，不要以为银行有很好的IT安全专家。 很多没有 。
也就是说，最大密码长度是毫无价值的。 它通常要求用户创build一个新的密码（关于在每个站点上使用不同密码的价值的争论），这增加了他们只写下它们的可能性。 这也大大增加了从任何暴力向社会工程传播的攻击的易感性。
现在，OWASP身份validation备忘单不鼓励最大密码长度限制
https://www.owasp.org/index.php/Authentication_Cheat_Sheet
引用整段：
更长的密码提供了更大的字符组合，因此使攻击者更难猜测。
密码的最小长度应由应用程序强制执行。 短于10个字符的密码被认为是弱的（[1]）。 虽然最小长度执行可能会导致某些用户记忆密码时出现问题，但是应用程序应该鼓励他们设置密码短语（句子或单词组合），这些密码可能比典型密码长得多，而且更容易记住。
最大密码长度不应设置得太低，否则会阻止用户创build密码。 典型的最大长度是128个字符。 短于20个字符的短语如果只包含小写的拉丁字符，通常被认为是弱的。 每个字符都计数！
确保用户input的每个字符实际上都包含在密码中。 我们已经看到了系统在比用户提供的长度更短的长度上截断密码（例如，当他们input20时，截断15个字符）。 这通常通过将所有密码input字段的长度设置为与最大长度密码的长度完全相同来处理。 如果您的最大密码长度很短，比如20-30个字符，这一点尤其重要。
我可以设想一个强制实施最大密码长度的原因是前端必须与许多传统系统后端接口，其中一个后端本身强制执行最大密码长度。
另一个思考过程可能是，如果一个用户被迫使用一个简短的密码，他们更容易发明随机的胡言乱语，而不是一个容易猜到的（通过他们的朋友/家人）的口号或绰号。 这种方法当然只有在前端执行混合数字/字母并拒绝包含任何字典单词的密码（包括用l33t表示的单词）时才有效。
强加一些最大密码长度的一个潜在的有效理由是散列它的过程（由于使用诸如bcrypt的慢散列函数）占用了太多的时间; 有些东西可能会被滥用，以便对服务器执行DOS攻击。
然后再次，服务器应该被configuration为自动删除需要很长时间的请求处理程序。 所以我怀疑这会是一个很大的问题。
我认为你在两点都非常正确。 如果他们正在存储密码散列，那么密码长度不会影响他们的数据库模式。 有一个开放式的密码长度会引发一个暴力攻击者必须考虑的variables。
除了糟糕的devise之外，很难看到限制密码长度的借口。
我能看到的最大密码长度的唯一好处是消除由于密码过长而导致的缓冲区溢出攻击的风险，但是有更好的方法来处理这种情况。
存储便宜，为什么限制密码长度。 即使你正在encryption密码，而不是仅对它进行散列，一个64个字符的string也不会比6个字符的string要encryption多了。
银行系统有可能覆盖旧的系统，所以他们只能允许一定的密码空间。
我的银行也这样做。 它曾经允许任何密码，我有一个20个字符。 有一天，我改变了它，看它给了我最多8个，并删除了我的旧密码中的非字母数字字符。 对我没有任何意义。
当我使用非字母数字的20字符密码时，银行的所有后端系统都工作过，所以遗留支持不是原因。 即使是这样，他们仍然应该允许你有任意的密码，然后做一个符合遗留系统要求的散列。 更好的是，他们应该修复遗留系统。
智能卡解决scheme不适合我。 我已经有了太多的卡片…我不需要另一个噱头。
如果您接受一个任意大小的密码，那么在散列之前，会出于性能原因而假定它被截断到窗帘长度。 截断的问题是，随着服务器性能的增加，在截断之前你不能轻易增加长度，因为它的哈希值显然是不同的。 当然，你可以有一个过渡期，两个长度都被哈希和检查，但是这使用更多的资源。
应该有最大的长度？ 这在IT方面是一个好奇的话题，更长的密码通常难以记住，因此更可能被logging下来（因为显而易见的原因，BIG禁止）。 更长的密码也往往被忘记，而这不一定是安全风险，可能会导致pipe理麻烦，生产力损失等。相信这些问题迫在眉睫的pipe理员可能会对密码施加最大的长度。
我个人相信这个具体的问题，给每个用户自己的。 如果你认为你可以记住一个40个字符的密码，那么所有的权力给你！
尽pipe如此，密码正在快速成为一种过时的安全模式，智能卡和证书authenticationcertificate是非常困难的，因为你所说的是一个问题，而且只有一个公钥需要存储在私有服务器端在任何时候您的卡/计算机上都有钥匙。
较长的密码或通行短语仅仅基于长度而难以破解，并且比需要复杂的密码更容易记住。
可能最好是去相当长（10+）的最小长度，限制长度无用。
传统的系统（已经提到）或连接外部供应商的系统可能需要8个字符的上限。 这也可能是误导用户自救的尝试。 限制它会导致系统中的pssw0rd1，pssw0rd2等密码太多。
密码不能被散列的一个原因是使用的validationalgorithm。 例如，某些摘要algorithm需要在服务器上使用纯文本版本的密码，因为身份validation机制涉及客户端和服务器对input的密码执行相同的math运算 （每次input的密码通常不会产生相同的输出与两台机器共享的随机生成的“随机数”相结合）。
通常情况下，这可以加强，因为摘要可以在一些情况下进行计算，但并不总是如此。 更好的方法是将密码与可逆encryption一起存储 – 这意味着应用程序源需要被保护，因为它们将包含encryption密钥。
Digst身份validation在那里允许通过其他非encryption通道进行身份validation。 如果使用SSL或其他全通道encryption，则不需要使用摘要authentication机制，这意味着可以将密码存储为散列（因为密码可以安全地通过线路以明文forms发送（对于给定的安全值）。
尽量不要施加任何限制，除非必要。 被警告：在很多不同的情况下，这可能也是必要的。 处理遗留系统是其中一个原因。 确保你很好的testing了很长的密码（你的系统能处理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/
只有8个字符长的密码听起来简直是错的 如果应该有一个限制，那么至less20个字符是更好的主意。
我认为应该应用的唯一的限制就像是一个2000字母的限制，或其他高得惊人的，但只限于数据库的大小，如果这是一个问题
