What's the point of maximum password lengths?

Greetings everyone,

Yesterday, I had a user message me asking why the passwords on my website were capped at 20 characters. I quickly found the "maximum password length" setting in the security options and saw that the default was 20. I went ahead and adjusted it to 255 for my website.

Before I made the adjustment, I briefly researched why maximum password lengths exist. It's clearly not about storage, because each password takes up exactly 73 characters in the database (13 for the salt and 60 for the hash.) The only other possible downside to infinite password lengths would be using up too much CPU hashing extremely long passwords, but I don't realistically see that being an issue with modern servers (you'd probably hit networking/POST limitations first.)

Furthermore, I found some people making very bold claims about the topic: "A maximum length specified on a password field should be read as a SECURITY WARNING... assume the worst and expect that this site is storing your password literally... avoid using this site like the plague if possible." (https://stackoverflow.com/questions/98768/should-i-impose-a-maximum-length-on-passwords)

And finally, I saw some suggestions that if there are back-end/network limitations for processing password lengths, it's best to silently truncate the input rather than returning an error message. After all, the password is hashed anyway, the user won't notice as long as the truncate length stays the same, and it's not like users would expect the first X characters to be non-sensitive information.

So, all of that said, does anyone know why there's a maximum password setting in Composr? I thought about posting this under Developing, but I'm going with Deploying because I'm not advocating for this option to be removed or anything, I'm just curious why it's there and what other people's thoughts about it are.

The reason is interoperability. Composr has support for storing passwords under different schemes, so that the passwords can easily be synched with legacy systems that have these kinds of limits.

We should raise the default to some huge number though.

Clearly this is now an issue with people now using password managers that generate long passwords.

I've put the default for the next patch release up to 255 . That's the max we can do in the DB field.
https://github.com/ocproducts/composr/commit/adb6534ae629fc3eca6a035bca1c138ffcf3519f

Correcting myself - the max we can do in the DB field, for if the password scheme is set to plain. If someone knows of anyone using passwords longer than 255 let me know please.

I get security and all, but why the heck would someone want such a long password anyways? They'd have to write it down or copy and paste it all the time, or have the browser remember it. Despite being harder to crack via brute-force, it still seems like the threat level would be about the same when taking into consideration, viruses that monitor keystrokes, clipboard data, or ones that eavesdrop on the contents of your files (in this case, it'd be the file where you store your long password).

Sorry I enjoy putting my two cents out there sometimes.

Joe said

I get security and all, but why the heck would someone want such a long password anyways? They'd have to write it down or copy and paste it all the time, or have the browser remember it.

From “Post #5,115”, 17th October 2018, 10:21 pm

As Chris said, I would assume one of the more common cases would be password managers (LastPass, KeePass/KeePassX, KWallet/GNOME Keyring, etc.) I don't use them myself, but I know they're quite popular with the technical crowd. When configured properly, they should generate properly diffucult passwords, and they shouldn't store the passwords on the disk in plaintext or anything insecure like you're suggesting. They're written specifically for this purpose, after all.

The other common case would be if someone is following the advice of this XKCD and using easy-to-remember sentences of English words, which can theoretically be harder to brute-force in this day and age where everyone knows the common tricks about using numbers and symbols.

Or the user could always be writing their passwords down on a Rollodex like I do. Can't hack that, and if someone unauthorized gets a hold of it, you've got bigger problems with your security, particularly on Layer 1.

jacobgkau said

When configured properly, they should generate properly diffucult passwords, and they shouldn't store the passwords on the disk in plaintext or anything insecure like you're suggesting.

Right. I meant more along the lines of the user storing it on their computer. If it's incredibly long, chances are if they don't have it written in their Rolodex, it's stored in a text file on their computer.

Joe said

jacobgkau said

When configured properly, they should generate properly diffucult passwords, and they shouldn't store the passwords on the disk in plaintext or anything insecure like you're suggesting.

Right. I meant more along the lines of the user storing it on their computer. If it's incredibly long, chances are if they don't have it written in their Rolodex, it's stored in a text file on their computer.

From “Post #5,117”, 18th October 2018, 1:15 am

Right, I'm just responding to your suggestion that long passwords must be easy for attackers to eavesdrop. If you're not aware of how a password manager works, the user only remembers one password for the manager itself, and the manager generates and remembers the rest of the passwords, which could be 100+ characters for all the user cares. As I said, password managers wouldn't just store those in a "text file," it would be a database file that's then encrypted in some fashion, depending on the program. If someone were to obtain the database from the disk, they wouldn't be able to read the passwords without cracking the master password and potentially needing to obtain something else required for decryption, e.g. a private key, which might be stored on a flash drive or other device.

Other attack surfaces (keyloggers, clipboard monitors, etc.) would vary in effectiveness based on the specific program and how it operates. I can tell you they wouldn't be much of a threat on a Linux distribution running Wayland (since Wayland isolates applications from reading each others' input and output), but I could see your concern on a poorly-secured Windows machine.

If you're just talking about the edge case of users keeping passwords in a .txt file, I'm sure that happens with short passwords, too. I would think most people who go out of their way to use 20+ character passwords would know not to store them in plaintext, but maybe my expectations are too high.

Just my two cents, as well.

Gotcha. Well no, I don't know how they work. I just imagined them being similar to a password generator like what cPanel offers, where they just generate a random password for each login. I guess there's a difference between a password generator and a password manager.

Still though, I like to keep my passwords not too short, but not too long to where I can't remember them!

Password managers don't require you to remember your passwords as long as the password exists in the database and they can also autofill the login input by default. Most of them can even autologin you into the associated website once you've entered the master password. The password your cPanel generated could be added to a password manager (such as LastPass the one I use) so you no longer need to remember and/or enter it (regardless of the length).

Not all passwords have to be generated by a password manager, it's easy to add any exisiting ones that you already use. Password managers offer to generate more complex passwords than cPanel as they don't need to be remembered and can easily be checked and revealed if required. Also (again using LastPass as an example) your password vault is available across many devices and is more secure than any native browser password manager.