> If you have to restrict the length, use maxlength in the input field.
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
but it's actually
i_love_peanut_butter_a
This may work for a time, but is likely to cause problems down the road.
Actually, please do NOT have a maxlength on your password field. Instead, if the contents are too long, disable the submit button and tell me my password is too long. Why? Because I never actually type in a password. I generate a long one and copy & paste it in. And when you put a max length on the field, I think my password is FooBarBazBatAwesome, and you think my password is FooBarBazBat.... and that is going to screw me.
I've had this happen on more than one occasion. For God's sake, do not put a max length on your password field. It silently drops any characters that are too long without notifying the user that it's doing so.
> If you have to restrict the length, use maxlength in the input 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.
YES!!!! TELL US THE DAMN PASSWORD RESTRICTIONS ON THE FORM BEFORE THE PASSWORD IS ENTERED!!
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)?
On a related topic, a troubling new trend (to me) is the reliance on passwords being automatically generated/kept by a tool. You are putting your trust in something else for something only you (or a select group) should be trusted with. If everyone were to start doing this or a vulnerability was found in it and exposed, then attackers would exclusively target the tool or the password store, making many at risk.
It is a trade off, because you have the ability to use significantly more complex passwords that are harder to brute force or guess using personal information. Just don't forget that you are providing new attack vectors in the process. If they access your password store and you didn't know about it, how at risk would you be if they were to unlock all of your passwords?
Do you really understand how the password store and password generator work?
The problem with really awful password interfaces lies mainly with big institutions (banks!) who are unlikely to be influenced by bloggers linked on hacker news.
Ever since switching to a password manager (1Password in my case) I've become acutely aware of how many places have ridiculous restrictions on passwords (especially maximum lengths and character restrictions), and the worst offenders are invariably banks and financial sector sites.
It seems like the more secure you need your data to be, the worse their password restrictions are. Restrictions such as no special characters, or an arbitrary short length raises a red flag. It says they don't really know what they are doing, and it makes me wonder what else is broken.
And no SQL keywords allowed in passwords. Because they like to advertise that they don't bother escaping user input before concatenating sql strings to store plain text passwords in the database.
The PHP manual pages are full of user comments with helpful suggestions just like that, which incompetent programmers copy and paste into production systems. But I think of it as a good thing, an instance of evolution in action, because banks that hire such stupid programmers deserve to have all their money stolen from them.
If you must have a maxlength, please be sensible. I've seen plenty of sites use 12 as max length - which is really not that much.
Also, requirements to what characters must be used (at least one number, at least one upper case letter) doesn't do much to increase security I think. Just let me enter whatever I want.
I hate sites that restrict how complex my password can be. Seriously, NemID, a Danish ID every person has that's used for everything (banking, among other things), don't allow special characters. What the heck. It's like they want it to be insecure.
Why would you have to restrict the length at all? I could see something like a few thousand characters max, to avoid making it easy to strain the server, but other than that, you're not supposed to store it as is anyway, and if you hash it, the input length doesn't really matter... what am I missing?
> Don't let a user submit a password which doesn't meet your requirements. Use JavaScript to disable the button and highlight the text of your password policy.
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.
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."
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.
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
but it's actually This may work for a time, but is likely to cause problems down the road.