Password Max Length limits can be really annoying. If you head over to the Dumb password Rules on Github you can see a heap of services with maximum length limits that have annoyed people. And I agree, these max length limits can be really annoying, but is removing the limit altogether the right answer? (spoiler: it isn't) How should we go about fixing our password fields?
People like to complain about password max lengths on twitter all. the. time. On Stack Overflow people even talk about there being no reason to limit password length and that max password lengths are a security warning. And worse than their complaining is the insistence that existence of password max lengths is the problem, and not the fact that the max limits are normally set really low (sometimes as low as 6 characters for banks).
Maximum lengths for passwords are a good thing to have. Long password denial of service is a thing that exists. Hashing algorithms that you use on the server side may have limits. More importantly, a known maximum password length allows you to test all of your password fields.
That last sentence might sound a bit weird, why would you need to test your login system? And why would you need to test long passwords? Think about everywhere that the password will be used.
The obvious places are login screens. These could be on your website, in a desktop app or in a mobile app. Do you know if all of these places let you type (or paste) a 1000 character password?
What about your registration pages, you need to enter the password twice there, as well as other information. Can those forms handle 2000 characters just for the password?
And the password reset pages. Now you need the current password and the new one twice. That's potentially 3000 characters that need to be entered.
What about everything else between the user and the password store. Does the Web Application Firewall allow that much data? Does your application and its frameworks accept long passwords? And how does the hashing algorithm deal with longer strings?
And finally, does your password change field let you enter a password longer than your login screen will allow like Paypal did?
If you are not testing your application to make sure that it can handle passwords set to the maximum length you allow, you can not be 100% certain that passwords at that max length will work throughout your system. And if you do not have a defined maximum length, then you can't test it.
So you should set a maximum password length and test it. But how long should it be? The OWASP Authentication Cheat Sheet has recommendations for implementing proper password strength controls.
Implement Proper Password Strength Controls (Abridged)
- A Minimum Length of 8 enforced to stop weak passwords
- Maximum length not set too low
- Do not truncate passwords
- Allow all characters (including unicode and whitespace)
- Rotate compromised credentials
- Include a password strength meter
- Disallow common and previously breached passwords
There are two key points from the recommendations that you need to keep in mind when setting the maximum allowable length for passwords; the limit you set for the password, and that you don't truncate user input.
The minimum you should set for the maximum password length should be sufficiently high (at least 100) so that anyone using a password manager is unlikely to be generating passwords that long.
If you set your password max length to 100 characters, every password field should allow you to type in at least 101 characters. This means that if a user uses a password manager to generate a 200 character password, your password set page has a chance to inform the user that they have entered too many characters and that they need to enter less.
So go out and set a password max length to the new project you're working on, figure out how to safely add one to your existing systems, and stay tuned if you want to hear about how to go about safely increasing a low password limit that you might already have.
Top comments (13)
Hi, I created the dumb password rules repository. Thanks for linking to it.
Most PRs that have been submitted have been concerned with maximum lengths like 8, 12, 16 characters or some unreasonably low number. I agree with your post that there needs to be some sufficiently high upper bound on password length. It just shouldn’t be as ridiculously low as many have it.
I have some additions to that list I need to submit based off of the research I did while working on this post. I had a look at Australian banks and their low password length limits. It's interesting looking at all of the (potential) decisions that were made in the past that led to the current state and why none of these were terrible decisions at the time.
I will happily review an PRs. I'm looking forward to your submissions.
Thanks for sharing your thoughts on this, Mitch. A maximum of 100 characters seems like a reasonable amount and one that even well-intentioned users with password managers likely won't have trouble with.
Except for the form submission limits you are simply wrong. Hashing passwords regardless their length can result in a fixed length hash. Therefore it does not matter the length of the password, as long as once encrypted it matches the database entry.
The password strength algorithms are stupid as most of them does not enable you to create a password that is a sentence, example "riding a horse tonight" which is a very strong password, can mean something to the user, easy to remember and very hard to crack.
Wrong how? And hashing and encryption are two different things that shouldn't be confused.
Yes hashing does mean that it will end up a fixed length, but before you get the hash you have:
You should be testing that all of them support the longest password you allow, which without max limit set is infinite and impossible to test.
Password Strength Meters - I think these should be indicative, rather than absolute. A minimum length password of all lowercase letters should be marked as insecure. Something more complex is better. Long and randomly generated is best. Disallowing previously breached and common passwords is more important than the password strength meter, but using them both together is a good way to give users visual, understandable feedback.
I frequently have my passwords rejected by a web site's max length requirements. Thank you for this article to help explain why the limits exist. A couple of quasi-off-topi comments:
Another password rule you sometimes see is limitations on certain special characters. I once came across a server that would crash when you used a certain special character in your password. Since then, when I run across a site that rejects certain special characters, I just assume they are running similar antiquated code that can't handle it.
One UX improvement I've started to see is websites that will tell you their password rules on their login screen (not just on the password set/change screen).
One thing I'd like to see sites start doing is explaining how they protect my password in the event of a data breach. I don't recycle passwords between sites, but I'd still like to know that my passwords are strongly hashed.
The OWASP recommendation is to no limit characters that are allowed in a password, but I think you need to have a tradeoff here. You should allow as large a character set as you can, but that means you need to test the character set, unless you want someone's password to take down your system.
I can't think of a good reason to state password rules on a login screen. If you have made your rules open enough, no one should be looking for what special characters are allowed, or a max length limit, or the number of upper case and lower case letters. What rules do you normally see on the sites that do this?
Explaining how you are securely storing data is hard. How much detail do you go into? What information do you leave out? And just because a site is telling you about their security practices, does it mean that they are really doing that?
So the initial justifications for password length limits are based on a fallacy of limiting length to allowing bad server side password hashing to exist instead of pushing for proper PBKDF2 like implementations that allow unlimited input & protect against DOS.
A better upper limit might be that which offers no additional entropy over the collision probability of the underlying digested output i.e. If the stored hash is say 128 bits then a password longer than this will by definition be a collision with one of this length i.e. 16 bytes / ASCII characters. This means for PBKDF2 with a SHA256 wrapper 32 bytes which may be as little as 8 UTF8 4 byte characters, which suggests any limit should be byte & not character based.
Finally! A good, common sense password policy.
I think most people complaining about password length limits mean "must be less than 32/16/8 characters", which is absurd. 100 is a good maximum.
I 100% agree, Mitch. Testability and denial of service risk reduction are super-important.
Thanks for writing this post.
can you please explain what you meant by "Rotate compromised credentials"
Rotate compromised credentials means forcing passwords and secrets to be changed if there is evidence or suspicion that someone who shouldn't have a copy of them has a copy of them.
A good example of this is when there has been a database breach/dump. Even if the passwords are hashed, there is the chance that the passwords could be brute force offline. You should get all users to set a new password so that of their old password is cracked offline it can not be used to log in.
Another example is finding API secrets on GitHub. Once these have been found, you know that they are no longer a secret and should invalidate them/force rotation of them. Even if the git history is changed to remove all traces of the secret you do not know if someone else has a copy of it already.