我应该允许2个字符的密码吗？

This may sound like a frivolous question, but those in the security field will get it. Should I let the user enter any number of characters as long as it's greater than 0 chars. My logic is:

  1. the password is going to be hashed and salted anyway, and
  2. it's more fun for someone doing a rainbow table to NOT have any length/other guidelines, but
  3. my concern is the brute force dictionary attacks.

Am I sort of on the right track with this?

Since I'm asking the lower limit question, I might as well ask about the upper limit? Again, it's going to be hashed and salted, so db size is not an issue. Then the only issue I can think of in this case is buffers more than anything else, right?

Update For those coming late to the question

So the general consensus seems to be confirming what I initially thought, that the risk of brute force increases. However, the RT cracker's job is not going to be made that much difficult by the fact that they have no clues as to the size. It may in fact be made easier since they start with lower character tables anyway. Correct? (Not to mention the non-technical concerns that have now come up with looking over someone's shoulder, etc. which aren't as big a concern for longer password.)

So the conclusion is: even if you hash/salt the password, short passwords are still a risk

For long passwords however, I'm not sure I have a conclusive answer? Should I worry about buffer overflows, it's still a regular input field after all.

No. Ideally passwords of 8 characters including numbers and characters is good. 14 or more characters would be even better.

Even if it will be hashed, the user types in a password, and 2 characters is trivial to break.

I think for an upper-end, why have a limit, but for a lower-end, 6 characters seems like a reasonable one, I would prefer that 7 be the minimum for security though.

#3 is the key: 2-3 char passwords are too vulnerable to dictionary attacks (too few combinations, and thus able to include the universe in the attack combinations).

Upper limit is irrelevant but anything over 20 characters means that the user is likely to be copying/pasting most, which is bad practice that should not be encouraged.

The people making the rainbow table will probably start with all 1-char length passwords and will then find the short passwords very quickly.

Regarding maximum length you should have none.

No. That's just silly.

If your passwords are properly hashed and salted, rainbow tables are a non-issue, incidentally.

It leaves your users very susceptible to strangers glancing over their shoulders, doesn't it?

Then, it doesn't really matter whether you black out the password characters in the form or not - if someone sees that they only have two characters in their password, it'll be easy for them to try combinations until they figure it out.

The problem with two-letter passwords is social engineering. Somebody may observe the user only typing two keys, and then a brute-force attack becomes realistic (even without writing a program).

If you can rule out such a case (because nobody would ever observe somebody typing a password), I'd argue that a two-letter password is fine even in the light of dictionary attacks. Somebody performing such an attack would still have to try out all realistic combinations, and if you don't prevent regular words from being used as passwords, there is no point in banning two-letter combinations.

It will leave the attacker with just 1296 options to guess the particular users password.

The security requirements should be created in relation to the worth of what is being protected and the damage (or liability caused by the damage) that can occur should it be compromised.

Sometimes these are mandated by an organization, client or protocol and turning to such sources for guidance may save hassle in the end and, in more secure cases, may include things such as the use of RSA fobs, security cards or finger-print readers.

Personally, I get annoyed when a site requires some terribly complicated password. I think that 6 characters, including one symbol/number is a fair requirement for, say, a site such as stackoverflow. On my bank account? Let's just say the password is a tad more complex.

But there are additional fundamental security concerns:

  • Brute force and dictionary attacks only practically work if tests may be applied [very] fast. This is why modern UNIX systems use a shadow password file -- it minimizes the chance of collecting passwords for brute force attacks. While "lockouts" can be annoying, they can also practically prevent simple brute forces.
  • Social engineering: "Can I play your character?" What's the name of your girlfriend? Do you write the password down or expose it while being entered? (Is anyone looking?) Is the password you use common for different sites/purposes?
  • Do other "features" circumnavigate security? Can a password be reset or is the current password e-mailed? What restrictions are there on a reset?
  • Is security compromised through other means (HTTP vs. HTTPS or telnet vs. SSH, accessible [plain-text] storage, etc.).
  • And by biggest peeve: Standard security questions. Google for "Sarah Palin Email Hacked". Please, please, please do not go down this route without careful consideration.

Let the user pick any password they want. Put a password strength meter up, but don't restrict the password. It is not your password, it is theirs.