How *NOT* To Do A Password Field

This bit is really bad advice. Maxlength stops you from typing but doesn't give you any indication it's happening, so I'd be happily typing out a 20 character password without realizing it's being lopped off somewhere.

If they ever lift the maxlength restriction, my password suddenly stops working for no apparent reason.

The problem with this approach is that, for longer passwords, the user may not be aware that the maxlength property has prevented the field accepting the last n characters of their password. They may believe they have successfully submitted their entire password. In other words, they may believe their password is

  i_love_peanut_butter_and_j3lly

  i_love_peanut_butter_a

If you are going that route, please change last line to:

"Use JavaScript to disable the button and highlight the text of your password policy (in addition to server-side validation)."

However, consider using a "poor password", "good password", "great password" approach that changes as you type and don't have a short max length in your validation, this way you can promote entering sufficient complex passwords of longer length. The best of these I've seen is a "progress bar"-looking thing under the password fields that also uses color changes (just don't use green as bad and red as good, and be aware of color-blindness/blindness) and text under it to describe how good or bad the password is.

Here is one of Microsoft's recommendations. It looks a lot like the cartoon in the post: http://technet.microsoft.com/en-us/library/cc786468%28v=ws.1...

That helps but is far from good enough. Read: http://en.wikipedia.org/wiki/Password_strength

Focus a bit on entropy to go with that colored-progress bar I talked about:

"It is usual in the computer industry to specify password strength in terms of information entropy, measured in bits, a concept from information theory. Instead of the number of guesses needed to find the password with certainty, the base-2 logarithm of that number is given, which is the number of "entropy bits" in a password. A password with, say, 42 bits of strength calculated in this way would be as strong as a string of 42 bits chosen randomly, say by a fair coin toss. Put another way, a password with 42 bits of strength would require 242 attempts to exhaust all possibilities during a brute force search. Thus, adding one bit of entropy to a password doubles the number of guesses required, which makes an attacker's task twice as difficult. On average, an attacker will have to try half of the possible passwords before finding the correct one."

Following on that with: http://en.wikipedia.org/wiki/Entropy_%28information_theory%2...

That states the limitations thereof, so entropy alone is not good enough:

"Limitations of entropy as a measure of unpredictability

In cryptanalysis, entropy is often roughly used as a measure of the unpredictability of a cryptographic key. For example, a 128-bit key that is randomly generated has 128 bits of entropy. It takes (on average) 2^{128-1} guesses to break by brute force. If the key's first digit is 0, and the others random, then the entropy is 127 bits, and it takes (on average) 2^{127-1} guesses.

However, entropy fails to capture the number of guesses required if the possible keys are not of equal probability.[17][18] If the key is half the time "password" and half the time a true random 128-bit key, then the entropy is approximately 65 bits. Yet half the time the key may be guessed on the first try, if your first guess is "password", and on average, it takes around 2^{126} guesses (not 2^{65-1}) to break this password.

Similarly, consider a 1000000-digit binary one-time pad. If the pad has 1000000 bits of entropy, it is perfect. If the pad has 999999 bits of entropy, evenly distributed (each individual bit of the pad having 0.999999 bits of entropy) it may still be considered very good. But if the pad has 999999 bits of entropy, where the first digit is fixed and the remaining 999999 digits are perfectly random, then the first digit of the ciphertext will not be encrypted at all."

But, even checking for common passwords (search and you can find numerous articles on that), etc. is not good enough. You must also tell people not to use easily guessable personal information in their passwords. Your birthdate, then "$" then your son's name then "$" then his birthdate may have "ok" entropy, but it would be easily hackable for anyone with elementary knowledge about the person.

That starts to get into the fallacy of security questions to reset your password, though. Security questions are terrible, and I cannot believe that financial institutions use them. If you hack the email account and know enough personal info, you bypass the password. That's bad.

But, everything is hackable, eventually. There are no hard rules that cannot be broken. Even our understanding of physics, etc. is incomplete. Anything is possible.

I hate hate hate hate (can't you tell I really hate it) when I use LastPass's awesome password generation, only to save and submit and then be told by the site the password is bad for whatever reason.

Please just do this. THEN we can start talking about those other restrictions (why is my password limited to 16 or even 32 characters?!?!).

Lots of frustration here, I'm pretty certain it's shared by a lot of people. Does feel better though :)

Now I'm not a web dev but I'm interested and echo the question that someone else posted below - why is there a length restriction on passwords (notwithstanding a restriction to stop strain on the server)?