Should I impose a maximum length on passwords?我可以理解，在密码上设置最小长度是很有意义的(这样可以节省用户的时间)，但是我的银行要求密码长度在6到8个字符之间，我开始想……
如果有人(希望)有一些优秀的IT安全专业人员为他们工作，他们要求密码的最大长度，我应该考虑做类似的事情吗？这有什么优点/缺点？ 密码被哈希到32、40、128，不管长度是多少。最小长度的唯一原因是防止容易猜测的密码。没有达到最大长度的目的。 强制性的XKCD解释了如果你强加一个最大长度，为什么你会伤害你的用户：
密码字段上指定的最大长度应作为安全警告读取：任何明智的、有安全意识的用户都必须假设最坏的情况，并期望这个站点能够准确地存储您的密码(如epochwolf所解释的那样，不是散列)。 在这种情况下：(a)如果可能的话，避免使用像瘟疫这样的网站[他们显然知道关于安全的疯狂](b)如果您必须使用该站点，请确保您的密码是唯一的-与您在其他地方使用的任何密码不同。 如果你正在开发一个接受密码的网站，不要设置一个愚蠢的密码限制，除非你想用同一个刷涂焦油。 [当然，在内部，您的代码可能只将前256/1028/2K/4K(无论什么)字节视为"重要"字节，以避免处理庞大的密码。] 如果您接受来自不可信来源的密码，那么允许完全无限制的密码长度有一个主要缺点。 发送者可能会给你一个很长的密码，从而导致其他人拒绝服务。例如，如果密码是1GB的数据，并且您花费所有的时间接受它，直到您耗尽内存。现在假设此人向您发送此密码的次数与您愿意接受的次数相同。如果不小心涉及的其他参数，这可能会导致DoS攻击。 按照今天的标准，将上限设置为256个字符似乎过于慷慨。 首先，不要假设银行有优秀的IT安全专业人员为他们工作。很多人不这样。 也就是说，最大密码长度是没有价值的。它通常要求用户创建一个新的密码(关于在每个站点上使用不同密码的价值的争论暂时搁置一边)，这增加了他们将只写下密码的可能性。它还大大增加了从蛮力到社会工程的任何媒介对攻击的敏感性。 OWASP身份验证备忘表现在不支持最大密码长度限制。 https://www.owasp.org/index.php/authenticationu作弊表 引用整个段落：
号 我可以想象强制使用最大密码长度的一个原因是前端必须与许多遗留系统后端接口，其中一个后端本身强制使用最大密码长度。 另一个思考过程可能是，如果一个用户被迫使用一个简短的密码，那么他们更可能创造出随机的胡言乱语，而不是一个容易猜到(由他们的朋友/家人)的短语或昵称。当然，这种方法只有在前端强制混合数字/字母，并拒绝使用任何字典单词(包括用L33T语言编写的单词)的密码时才有效。 强制使用某些最大密码长度的一个潜在的有效原因是哈希过程(由于使用了诸如bcrypt之类的慢速哈希函数)占用了太多时间；这可能会被滥用以对服务器执行DoS攻击。 然后，服务器应该配置为自动删除耗时太长的请求处理程序。所以我怀疑这会是个大问题。 我认为你在这两个要点上都很正确。如果他们像应该的那样存储散列的密码，那么密码长度不会影响他们的DB模式。如果密码长度是开放的，则会引发另一个变量，这是暴力攻击者必须解释的。 除了糟糕的设计，很难找到限制密码长度的任何借口。 我能看到的最大密码长度的唯一好处是消除了由于密码过长而导致缓冲区溢出攻击的风险，但是有更好的方法来处理这种情况。 如果您接受一个任意大小的密码，那么在散列它之前，我们假设它由于性能原因被截断为一个帷幕长度。截断的问题是，随着时间的推移，服务器性能的提高，您不能轻易地增加截断前的长度，因为它的散列值明显不同。当然，您可以有一个过渡期，在这个过渡期中对两个长度进行哈希和检查，但这会使用更多的资源。 我的银行也这么做。它允许任何密码，我有一个20个字符的密码。有一天，我换了一个密码，结果发现它给了我最多8个，并且删掉了我旧密码中的非字母数字字符。对我来说毫无意义。 银行的所有后端系统在我使用非字母数字的20个字符密码之前都工作过，所以不能将遗留支持作为原因。即使是这样，它们仍然应该允许您拥有任意的密码，然后根据遗留系统的要求进行散列。更好的是，他们应该修复遗留系统。 智能卡解决方案不适合我。我已经有太多的牌了…我不需要再耍花招了。 忽略那些说不要验证长密码的人。OWASP字面意思是128个字符就足够了。只要给你足够的呼吸空间，如果你愿意的话，你可以多给300，250，500。 https://www.owasp.org/index.php/authentication_作弊表密码长度
号 存储很便宜，为什么要限制密码长度。即使您正在加密密码，而不是仅仅对其进行哈希运算，64个字符的字符串加密所需的时间也不会超过6个字符。 很可能是银行系统覆盖了一个旧的系统，所以他们只能为密码留出一定的空间。 是否应该有最大长度？这是一个奇怪的话题，因为更长的密码通常很难记住，因此更容易被写下来(一个明显的原因是巨大的拒绝)。更长的密码也容易被遗忘，这虽然不一定是一个安全风险，但可能会导致管理麻烦，生产力下降等。管理员认为这些问题是紧迫的，可能会对密码施加最大长度。 我个人相信这个特定的问题，给每个用户自己的。如果你认为你能记住一个40个字符的密码，那么你就有更多的权力了！ 尽管如此，密码正迅速成为一种过时的安全模式，智能卡和证书认证证明非常困难，不可能像您所说的那样暴力，这是一个问题，只有一个公钥需要在服务器端与您的卡/计算机上的私钥一起随时存储。 较长的密码，或传递短语，很难简单地根据长度破解，而且比需要复杂的密码更容易记住。最好是选择一个相当长(10+以上)的最小长度，限制长度无效。 遗留系统(已提到)或供应商系统外部的接口可能需要8个字符的上限。这也可能是一个错误的尝试，以拯救用户自己。以这种方式限制会导致系统中的pssw0rd1、pssw0rd2等密码过多。 密码不能散列的一个原因是使用的身份验证算法。例如，一些摘要算法要求在服务器上使用明文版本的密码，因为身份验证机制涉及客户端和服务器对输入的密码执行相同的数学运算(通常不会每次生成相同的输出，因为密码与随机生成的"nonce"组合在一起，即shar两台机器之间)。 这通常可以得到加强，因为在某些情况下可以部分计算消化，但并非总是如此。更好的方法是使用可逆加密来存储密码——这意味着应用程序源需要受到保护，因为它们将包含加密密钥。 digst auth允许通过其他非加密通道进行身份验证。如果使用ssl或其他全通道加密，则无需使用摘要式身份验证机制，这意味着可以将密码存储为散列(因为密码可以安全地通过网络明文发送(对于给定的safe值)。 除非必要，尽量不要施加任何限制。警告：在许多不同的情况下，这可能也是必要的。处理遗留系统就是其中一个原因。确保您测试了非常长的密码(您的系统能处理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/ 我认为唯一应该应用的限制是像2000个字母的限制，或者其他一些不太高的限制，但是如果这是一个问题，只限制数据库的大小。 只有8个字符长的密码听起来完全错误。如果应该有限制，那么至少20个字符更好。 |
。
