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 maximu...
For further actions, you may consider blocking this person and/or reporting abuse
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.