blocks|key|363977|text|存储很便宜，为什么要限制密码长度。即使您正在加密密码，而不仅仅是散列它，64个字符串也不会比6个字符串多花多少时间来加密。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|363978|银行系统很可能覆盖了一个较旧的系统，因此他们只能为密码留出一定的空间。|363979|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Storage is cheap, why limit the password length. Even if you're encrypting the password as opposed to just hashing it a 64 character string isn't going to take much more than a 6 character string to encrypt.

Chances are the bank system is overlaying an older system so they were only able to allow a certain amount of space for the password.

blocks|key|367354|text|密码被散列为32、40、128，无论长度如何。设置最小长度的唯一原因是防止容易猜到密码。最大长度是没有意义的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|367355|强制性的XKCD解释了为什么如果你强加一个最大长度，你就会伤害你的用户：|offset|length|367356|​|367357|📷|atomic|367358|367359|entityMap|0|LINK|mutability|MUTABLE|url|http://xkcd.com/936/|1|IMAGE|IMMUTABLE|imageUrl|https://ask.qcloudimg.com/http-save/yehe-900000/be970f21223af9cf2788cfb344bc4b0e.png|imageAlt^0|0|4|4|0|0|0|0|1|1|0|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|10|8|@]|9|@$D|11|E|12|1|13]]|A|$]]|$1|F|3|G|5|6|7|14|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|15|8|@]|9|@$D|16|E|17|1|18]]|A|$]]|$1|K|3|G|5|6|7|19|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]]|M|$N|$5|O|P|Q|A|$R|S]]|T|$5|U|P|V|A|$W|X|Y|-4]]]]

Passwords are hashed to 32, 40, 128, whatever length. The only reason for a minimum length is to prevent easy to guess passwords. There is no purpose for a maximum length.

The obligatory <a href="http://xkcd.com/936/" rel="noreferrer">XKCD</a> explaining why you're doing your user a disservice if you impose a max length:

<a href="http://xkcd.com/936/" rel="noreferrer" title="To anyone who understands information theory and security and is in an infuriating argument with someone who does not (possibly involving mixed case), I sincerely apologize."><img src="https://imgs.xkcd.com/comics/password_strength.png" alt="The obligatory XKCD"></a>

blocks|key|3156892|text|我认为你在两个要点上都是非常正确的。如果他们存储的密码是散列的，那么密码长度不会影响他们的DB模式。如果密码长度是开放的，则会抛出另一个变量，这是暴力破解攻击者必须考虑的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3156893|除了糟糕的设计之外，很难看到限制密码长度的任何借口。|3156894|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I think you're very right on both bullet points. If they're storing the passwords hashed, as they should, then password length doesn't affect their DB schema whatsoever. Having an open-ended password length throws in one more variable that a brute-force attacker has to account for.

It's hard to see any excuse for limiting password length, besides bad design.

blocks|key|3369848|text|首先，不要假设银行有优秀的IT安全专业人员为他们工作。Plenty+don't。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3369849|也就是说，最大密码长度是毫无价值的。它通常要求用户创建一个新密码(暂时不讨论在每个网站上使用不同密码的价值)，这增加了他们直接写下密码的可能性。它还极大地增加了从暴力到社会工程的任何媒介攻击的敏感性。|3369850|entityMap|0|LINK|mutability|MUTABLE|url|http://thedailywtf.com/Articles/WishItWas-TwoFactor-.aspx^0|R|C|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

First, do not assume that banks have good IT security professionals working for them. <a href="http://thedailywtf.com/Articles/WishItWas-TwoFactor-.aspx" rel="noreferrer">Plenty don't</a>.

That said, maximum password length is worthless. It often requires users to create a new password (arguments about the value of using different passwords on every site aside for the moment), which increases the likelihood they will just write them down. It also greatly increases the susceptibility to attack, by any vector from brute force to social engineering.

blocks|key|3369887|text|应该有一个最大长度吗？这在IT领域是一个奇怪的话题，因为较长的密码通常更难记住，因此更有可能被记录下来(由于显而易见的原因，这是一个大禁忌)。较长的密码也容易被遗忘更多，这虽然不一定是安全风险，但可能会导致管理麻烦，失去工作效率等。认为这些问题紧迫的管理员可能会对密码施加最大长度。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3369888|我个人认为，在这个特定的问题上，每个用户都有自己的想法。如果你认为你可以记住一个40个字符的密码，那么你就更有能力了！|3369889|话虽如此，密码正迅速成为一种过时的安全模式，智能卡和证书身份验证被证明是非常困难的，因为您所说的暴力破解是一个问题，并且只需要将公钥存储在服务器端，并始终使用卡/计算机上的私钥。|3369890|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Should there be a maximum length? This is a curious topic in IT in that, longer passwords are typically harder to remember, and therefore more likely to get written down (a BIG no-no for obvious reasons). Longer passwords also tend to get forgotten more, which while not necessarily a security risk, can lead to administrative hassles, lost productivity, etc. Admins who believe that these issues are pressing are likely to impose maximum lengths on passwords.

I personally believe on this specific issue, to each user their own. If you think you can remember a 40 character password, then all the more power to you! 

Having said that though, passwords are fast becoming an outdated mode of security, Smart Cards and certificate authentication prove very difficult to impossible to brute force as you stated is an issue, and only a public key need be stored on the server end with the private key on your card/computer at all times.

blocks|key|3156991|text|更长的密码，或口令短语，很难简单地根据长度破解，而且比要求复杂的密码更容易记住。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3156992|也许最好的做法是选择一个相当长的(10%2B)最小长度，限制这个长度是无用的。|3156993|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Longer passwords, or pass-phrases, are harder to crack simply based on length, and easier to remember than requiring a complex password. 
Probably best to go for a fairly long (10+) minimum length, restricting the length useless.

blocks|key|3157005|text|我能看到的最大密码长度的唯一好处是消除了由过长的密码引起的缓冲区溢出攻击的风险，但有更好的方法来处理这种情况。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3157006|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The only benefit I can see to a maximum password length would be to eliminate the risk of a buffer overflow attack caused by an overly long password, but there are much better ways to handle that situation.

blocks|key|362647|text|如果您接受来自不受信任来源的密码，则允许完全无限制的密码长度有一个主要缺点。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|362648|发件人可能会尝试为您提供过长的密码，从而导致拒绝为其他人提供服务。例如，如果密码是1+1GB的数据，并且您花费了所有时间来接受它，直到内存耗尽。现在，假设此人向您发送此密码的次数与您愿意接受的次数相同。如果您不注意涉及到的其他参数，这可能会导致DoS攻击。|362649|以今天的标准来看，将上限设置为256个字符似乎过于慷慨了。|362650|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Allowing for completely unbounded password length has one major drawback if you accept the password from untrusted sources.

The sender could try to give you such a long password that it results in a denial of service for other people. For example, if the password is 1GB of data and you spend all your time accept it until you run out of memory. Now suppose this person sends you this password as many times as you are willing to accept. If you're not careful about the other parameters involved this could lead to a DoS attack.

Setting the upper bound to something like 256 chars seems overly generous by today's standards.

blocks|key|3157035|text|仅仅8个字符的密码听起来就是错误的。如果应该有一个限制，那么至少20个字符是更好的主意。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3157036|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Just 8 char long passwords sound simply wrong. If there ought to be a limit, then atleast 20 char is better idea.

blocks|key|367456|text|我可以想象强制执行最大密码长度的一个原因是，如果前端必须与许多遗留系统后端交互，其中一个后端本身强制执行最大密码长度。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|367457|另一种思考过程可能是，如果用户被迫使用简短的密码，他们更有可能发明随机的胡言乱语，而不是(被他们的朋友/家人)容易猜到的流行语或昵称。当然，这种方法只有在前端强制混合数字/字母并拒绝具有任何字典单词的密码时才有效，包括用l33t-speak写的单词。|367458|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

One reason I can imagine for enforcing a maximum password length is if the frontend must interface with many legacy system backends, one of which itself enforces a maximum password length.

Another thinking process might be that if a user is forced to go with a short password they're more likely to invent random gibberish than an easily guessed (by their friends/family) catch-phrase or nickname. This approach is of course only effective if the frontend enforces mixing numbers/letters and rejects passwords which have any dictionary words, including words written in l33t-speak.

blocks|key|362698|text|遗留系统(已经提到)或连接外部供应商的系统可能需要8个字符的上限。这也可能是一种误导性的尝试，试图将用户从他们自己手中拯救出来。以这种方式限制它将导致系统中的pssw0rd1、pssw0rd2等密码过多。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|362699|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Legacy systems (mentioned already) or interfacing outside vendor's systems might necessitate the 8 character cap. It could also be a misguided attempt to save the users from themselves. Limiting it in that fashion will result in too many pssw0rd1, pssw0rd2, etc. passwords in the system.

blocks|key|367524|text|我的银行也是这样做的。它过去允许任何密码，而我有一个20个字符的密码。有一天，我更改了密码，你瞧，它给了我最多8个密码，并且删除了我旧密码中的非字母数字字符。对我来说没有任何意义。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|367525|以前，当我使用20个字符的非字母数字密码时，银行的所有后端系统都能正常工作，所以遗留支持不可能是原因。即使是这样，它们也应该允许您使用任意的密码，然后生成符合遗留系统要求的散列。更好的是，他们应该修复遗留系统。|367526|智能卡解决方案不适合我。我已经有太多的牌了.我不需要另一个花招。|367527|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

My bank does this too. It used to allow any password, and I had a 20 character one. One day I changed it, and lo and behold it gave me a maximum of 8, and had cut out non-alphanumeric characters which were in my old password. Didn't make any sense to me.

All the back-end systems at the bank worked before when I was using my 20 char password with non alpha-numerics, so legacy support can't have been the reason. And even if it was, they should still allow you to have arbitrary passwords, and then make a hash that fits the requirements of the legacy systems. Better still, they should fix the legacy systems.

A smart card solution would not go well with me. I already have too many cards as it is... I don't need another gimmick.

blocks|key|364165|text|密码字段中指定的最大长度应读取为安全警告。任何明智的，有安全意识的用户都必须做最坏的打算，并期望这个站点按字面意思存储您的密码(即，不是散列的，就像epochwolf所解释的那样)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|364166|在这种情况下：|364167|364168|如果可能，避免像使用瘟疫一样使用本网站。他们显然对安全一无所知。|ordered-list-item|364169|如果你真的必须使用该网站，请确保你的密码是唯一的-不像你在其他地方使用的任何密码。|364170|364171|如果你正在开发一个接受密码的网站，不要设置一个愚蠢的密码限制，除非你想被相同的刷子弄得焦头烂额。|364172|当然，在内部，您的代码可能只将前256/1024/2k/4k/(随便什么)字节视为“重要”字节，以避免处理庞大的密码。|364173|entityMap^0|G|4|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@$9|V|A|W|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|X|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|Y|8|@]|D|@]|E|$]]|$1|I|3|J|5|K|7|Z|8|@]|D|@]|E|$]]|$1|L|3|M|5|K|7|10|8|@]|D|@]|E|$]]|$1|N|3|-4|5|6|7|11|8|@]|D|@]|E|$]]|$1|O|3|P|5|6|7|12|8|@]|D|@]|E|$]]|$1|Q|3|R|5|6|7|13|8|@]|D|@]|E|$]]|$1|S|3|-4|5|6|7|14|8|@]|D|@]|E|$]]]|T|$]]

A maximum length specified on a password field should be read as a SECURITY WARNING. Any sensible, security conscious user must assume the worst and expect that this site is storing your password literally (i.e. not hashed, as explained by epochwolf).

In that that is the case:

<ol>
<li>Avoid using this site like the plague if possible. They obviously know nothing about security.</li>
<li>If you truly must use the site, make sure your password is unique - unlike any password you use elsewhere.</li>
</ol>

If you are developing a site that accepts passwords, do not put a silly password limit, unless you want to get tarred with the same brush.

[Internally, of course your code may treat only the first 256/1024/2k/4k/(whatever) bytes as "significant", in order to avoid crunching on mammoth passwords.]

blocks|key|364552|text|我认为应该应用的唯一限制是2000个字母的限制，或者是其他一些非常高的限制，但只有在有问题的情况下才限制数据库大小。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|364553|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I think the only limit that should be applied is like a 2000 letter limit, or something else insainly high, but only to limit the database size if that is an issue

blocks|key|3370110|text|设置某些最大密码长度的一个潜在有效原因是，散列密码的过程(由于使用了较慢的散列函数，如bcrypt)占用了太多时间；这些时间可能会被滥用，以便对服务器执行DOS攻击。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3370111|然后，服务器应该配置为自动删除耗时太长的请求处理程序。所以我怀疑这不会是个大问题。|3370112|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

One potentially valid reason to impose some maximum password length is that the process of hashing it (due to the use of a slow hashing function such as bcrypt) takes up too much time; something that could be abused in order to execute a DOS attack against the server.

Then again, servers should be configured to automatically drop request handlers that take too long. So I doubt this would be much of a problem.

blocks|key|3370153|text|OWASP身份验证小抄现在不鼓励设置少于128个字符的最大密码长度|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3370154|https://www.owasp.org/index.php/Authentication_Cheat_Sheet|offset|length|3370155|引用了整段话：|3370156|3370157|较长的密码提供了更多的字符组合，从而使攻击者更难猜测。|blockquote|3370158|3370159|密码的最小长度应由应用程序强制执行。少于10个字符的密码被视为弱密码(1)。虽然强制实施最小长度可能会导致一些用户在记忆密码时出现问题，但应用程序应该鼓励他们设置口令短语(句子或单词组合)，这些口令短语可以比典型的密码长得多，而且更容易记住。|3370160|最大密码长度不应设置得太低，因为这会阻止用户创建密码短语。典型的最大长度为128个字符。短于20个字符的密码短语如果仅由小写的拉丁字符组成，则通常被认为是弱密码。每一个字符都很重要！！|3370161|确保用户键入的每个字符都包含在密码中。我们已经看到系统截断密码的长度比用户提供的长度短(例如，当用户输入20时，将密码截断为15个字符)。这通常通过将所有密码输入字段的长度设置为与最大长度密码完全相同的长度来处理。如果您的最大密码长度很短，例如20-30个字符，这一点尤其重要。|3370162|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|1M|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|10|8|@]|9|@$D|11|E|12|1|13]]|A|$]]|$1|F|3|G|5|6|7|14|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|15|8|@]|9|@]|A|$]]|$1|I|3|J|5|K|7|16|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|17|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|18|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|19|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1A|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]]|T|$U|$5|V|W|X|A|$Y|C]]]]

Setting maximum password length less than 128 characters is now discouraged by OWASP Authentication Cheat Sheet

<a href="https://www.owasp.org/index.php/Authentication_Cheat_Sheet" rel="noreferrer">https://www.owasp.org/index.php/Authentication_Cheat_Sheet</a>

Citing the whole paragraph:

<blockquote>
 Longer passwords provide a greater combination of characters and consequently make it more difficult for an attacker to guess.
 
 Minimum length of the passwords should be enforced by the application.
 Passwords shorter than 10 characters are considered to be weak ([1]).
 While minimum length enforcement may cause problems with memorizing passwords among some users, applications should encourage them to set passphrases (sentences or combination of words) that can be much longer than typical passwords and yet much easier to remember.
 
 Maximum password length should not be set too low, as it will prevent users from creating passphrases. Typical maximum length is 128 characters.
 Passphrases shorter than 20 characters are usually considered weak if they only consist of lower case Latin characters. Every character counts!!
 
 Make sure that every character the user types in is actually included in the password. We've seen systems that truncate the password at a length shorter than what the user provided (e.g., truncated at 15 characters when they entered 20).
 This is usually handled by setting the length of ALL password input fields to be exactly the same length as the maximum length password. This is particularly important if your max password length is short, like 20-30 characters.
</blockquote>

blocks|key|3157307|text|密码不能散列的一个原因是所使用的身份验证算法。例如，一些digest+algorithms需要服务器上的明文版本的密码，因为身份验证机制涉及客户端和服务器对输入的密码执行相同的数学运算(这通常不会在每次密码与随机生成的“随机数”组合时产生相同的输出，该“随机数”在两台机器之间共享)。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3157308|通常可以加强这一点，因为在某些情况下，摘要可以部分计算，但并不总是如此。更好的方法是使用可逆加密存储密码-这意味着应用程序源需要受到保护，因为它们将包含加密密钥。|3157309|Digst身份验证允许在其他非加密通道上进行身份验证。如果使用SSL或其他全通道加密，则不需要使用摘要身份验证机制，这意味着密码可以散列存储(因为密码可以通过网络安全地以明文形式发送(对于给定的safe值)。|3157310|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Digest_access_authentication^0|S|H|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]]]

One reason passwords may not be hashed is the authentication algorithm used. For example, some <a href="http://en.wikipedia.org/wiki/Digest_access_authentication" rel="nofollow">digest algorithms</a> require a plaintext version of the password at the server as the authentication mechanism involves both the client and the server performing the same maths on the entered password (which generally won't produce the same output each time as the password is combined with a randomly generated 'nonce', which is shared between the two machines).

Often this can be strengthened as the digest can be part computed in some cases, but not always. A better route is for the password to be stored with reversible encryption - this then means the application sources need to be protected as they'll contain the encryption key.

Digst auth is there to allow authentication over otherwise non-encrypted channels. If using SSL or some other full-channel encryption, then there's no need to use digest auth mechanisms, meaning passwords can be stored hashed instead (as passwords could be sent plaintext over the wire safely (for a given value of safe).

blocks|key|3370227|text|如果您接受任意大小的密码，则假设在对其进行散列之前，出于性能原因将其截断为窗帘长度。截断的问题是，随着您的服务器性能随着时间的推移而提高，您不能在截断之前轻松地增加长度，因为它的散列显然是不同的。当然，您可以有一个过渡期，其中两个长度都会进行散列和检查，但这会占用更多的资源。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3370228|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

If you accept an arbitrary sized password then one assumes that it is getting truncated to a curtain length for performance reasons before it is hashed. The issue with truncation is that as your server performance increases over time you can't easily increase the length before truncation as its hash would clearly be different. Of course you could have a transition period where both lengths are hashed and checked but this uses more resources.

blocks|key|364637|text|尽量不要强加任何限制，除非有必要。请注意:在许多不同的情况下，它可能并将是必要的。处理遗留系统就是这些原因之一。确保很好地测试了超长密码的大小写(您的系统可以处理10MB长密码吗？)您可能会遇到拒绝服务(DoS)问题，因为您将使用的密钥定义函数(通常是PBKDF2、bcrypt、scrypt)将占用大量的时间和资源。现实生活中的例子：http://arstechnica.com/security/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-security/|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|364638|entityMap|0|LINK|mutability|MUTABLE|url|http://arstechnica.com/security/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-security/^0|4O|30|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Try not to impose any limitation unless necessary. Be warned: it might and will be necessary in a lot of different cases. Dealing with legacy systems is one of these reasons. Make sure you test the case of very long passwords well (can your system deal with 10MB long passwords?). You can run into Denial of Service (DoS) problems because the Key Defivation Functions (KDF) you will be using (usually PBKDF2, bcrypt, scrypt) will take to much time and resources. Real life example: <a href="http://arstechnica.com/security/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-security/" rel="nofollow">http://arstechnica.com/security/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-security/</a>

blocks|key|364281|text|忽略那些说不要验证长密码的人。Owasp字面上说128个字符应该足够了。只要给你足够的呼吸空间，你可以多给一点，比如300,250,500，如果你想的话。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|364282|https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Password_Length|offset|length|364283|364284|密码长度较长的密码提供了更多的字符组合，从而使攻击者更难猜测。|blockquote|364285|364286|..。|364287|最大密码长度不应设置得太低，因为这会阻止用户创建密码短语。典型的最大长度是128个字符的。短于20个字符的密码短语如果只包含小写的拉丁字符，则通常被认为是弱密码。|style|BOLD|364288|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|22|0|0|0|0|0|0|T|F|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Y|8|@]|9|@$D|Z|E|10|1|11]]|A|$]]|$1|F|3|-4|5|6|7|12|8|@]|9|@]|A|$]]|$1|G|3|H|5|I|7|13|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|14|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|15|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|16|8|@$D|17|E|18|O|P]]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|19|8|@]|9|@]|A|$]]]|R|$S|$5|T|U|V|A|$W|C]]]]

Ignore the people saying not to validate long passwords. Owasp literally says that 128 chars should be enough. Just to give enough breath space you can give a bit more say 300, 250, 500 if you feel like it.

<a href="https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Password_Length" rel="nofollow noreferrer">https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Password_Length</a>

<blockquote>
 Password Length Longer passwords provide a greater combination of
 characters and consequently make it more difficult for an attacker to
 guess.
 
 ...
 
 Maximum password length should not be set too low, as it will prevent
 users from creating passphrases. Typical maximum length is 128
 characters. Passphrases shorter than 20 characters are usually
 considered weak if they only consist of lower case Latin characters.
</blockquote>

I can understand that imposing a minimum length on passwords makes a lot of sense (to save users from themselves), but my bank has a requirement that passwords are between 6 and 8 characters long, and I started wondering...

<ul>
<li>Wouldn't this just make it easier for brute force attacks? (Bad)</li>
<li>Does this imply that my password is being stored unencrypted? (Bad)</li>
</ul>

If someone with (hopefully) some good IT security professionals working for them are imposing a max password length, should I think about doing similar? What are the pros/cons of this?

Should I impose a maximum length on passwords?

网络安全

身份验证

数据库

服务器

我可以理解，对密码设置最小长度是很有意义的(为了保护用户)，但是我的银行要求密码长度在6到8个字符之间，我开始怀疑……难道不会让暴力攻击变得更容易吗？(坏)这是否意味着我的密码是未加密存储的？(坏)如果有人(希望)有一些优秀的IT安全专业人员为他们工作，他们强制使用最大密码长度，我是否应该考虑这样做？这样做的利弊是什么...

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

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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