You're Making Passwords Bad
2023-01-10 20:03:28 UTC
Your password rules are stupid. Your password logic is stupid. Password composition rules are stupid. Stop requiring them. They don't do what you think they do. You think you're making passwords more secure but you're actually make them less secure.
The one thing that makes a password work is entropy. A valid password needs to be one of a vast set of available passwords. By adding restrictions, you are reducing entropy. Moreover, by adding restrictions, you're incentivizing users to come up with patterns that reduce entropy even more.
Max password limits. Why are you doing this? I can understand a max limit if you're trying to ensure passwords come under some transport or memory limit. But eight characters? Fifteen? Even fifty is absurd. Let my password be as long as I wish (again, so long as it's not butting up against some transport or memory limit) If you need a maximum limit because you are storing anything other than a hash, then shame on you.
ASCII only. Why? Why not Japanese characters? Arabic characters? Emojis? Why are you restricting passwords this way?
Truncation. What the fuck is this about? Why are you truncating people's passwords? Worse is when you do it silently. What is the point of this? Bonus points if you silently truncate on password creation but don't truncate at all on login.
Limited special characters. Why do this? You are sanitizing your inputs, right? Right?
Requiring x upper-case letters, y lower-case letters, and z arabic numerals. All you're doing here is transforming "password" in to "P4ssw0rd".
Password rotation. I get that you think requiring a rotating password means it's more secure but what you're really doing is making people come up with a work-around to keep the same password. password1234!01, password1!23402, password12!3403, etc. I can understand rotation for systems that require stringent security. For an average user on an average system (yes, your system is probably average) then only require password rotation when some event triggers it, like a breach.
Client-side password hashing. This blows my mind. If you hash on the client side and transmit the hash, that hash is effectively the password. Send up the plaintext (using SSL or some encrypted transport route, please) and hash it on the server.
You want increased entropy. By employing ridiculous restrictions, you're not only incentivizing users to come up with tricks to work around your rules but you're punishing those who randomly generate their passwords. You're acting directly against the goals you're trying to achieve. So, what rules can you employ?
- Let users enter any Unicode character they want.
- Allow maximum password lengths that are restricted only by transport or memory constraints.
- Minimum password lengths can help weed out common short passwords.
- You can check a password against a list of common passwords. This can include dynamic values such as a user's username or part of their user record.
- You can check for patterns in a password. Passwords like "wheewheewhee", "blaaaaaaaaaaaaaaa", or "12345678910" can all be detected and disallowed.
One final note: I would not disallow common words. Passphrases should be acceptable. They can help increase the length of a password while still allowing a user to remember what the passphrase is.