Password Rules (2 Part Series)
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.