Not directly related but prompted by Pwned Passwords Validator since we have been looking into stronger password validation lately.
Discourse does not appear to block a password like myusername123 or 4myusername for the username myusername.
I didn’t find any past discussion on this specific kind of weak password. Has this been considered before?
I am fine to add a check when people pick a password for “password shall not contain username_lower” it seems reasonable to me.
We already test for password = username but I’m not a big fan of substring tests, especially for shorter usernames. What if your username is “Ed” and your password is a random string that happens to contain “ed”…
Using a similarity score like Levenshtein distance, fail if levenshtein(username, password) < 6 ? Or even something to catch permutations too, like this:
levenshtein(sort_by_chars(username), sort_by_chars(password)) < 6
That seems like it would cover the worst abuses, without prohibiting “Ed” from signing up with a nice long password, and it’s easy to explain accurately: “your username and password are too similar”. I haven’t looked for undesirable edge cases but I can’t think of any at the moment.
Related tweet from today:
The flip side of “more and more” rules is that it becomes easier to brute force passwords.
Clearly no password should have the letter z repeated 10 times if it is 15 chars or shorter.
Clearly no password should have the word password in it. If it is shorter than 12.
Two dictionary words in a row, clearly wrong…
And so on. So the space for searching for passwords is shrunk.
This is a rabbit hole, I have changed my mind from yesterday after thinking about this. I am with @codinghorror I don’t think we need to do anything here.
“It’s hard to make good rules, so we shouldn’t make rules” ?
This is the second time in as many days that I’ve seen high-level members of the Discourse team spreading major misconceptions about security. I think there are some general things you need to re-think and I hope you will take that as constructive feedback.
Also, this specific suggestion isn’t coming out of nowhere: we recently had a user account get compromised because the username was myusername and the password was of the form myusername46.
Granted this was a ClassicPress site (same login structure as WordPress) so it is much more “low-hanging fruit” in terms of bots etc. However this is something that bots are looking for.
Password rules can’t prevent every kind of bad password out there, but they can go a long way.
Technically we are following the guidelines of NIST 800-63-B:
When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include, but is not limited to:
- Passwords obtained from previous breach corpuses.
- Dictionary words.
- Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).
- Context-specific words, such as the name of the service, the username, and derivatives thereof.
They explicitly use the word MAY not SHALL. So this is to our discretion. There is no recommendation for Levenshtien here. Maybe if username longer than 6 then it should not be included in password maybe we could add an entropy check on top of the 1 million password list. I don’t know.
I guess if you are super keen to have your own rules here run SSO and have whatever rules you want on your end. Or write a plugin.
This is probably what we’re going to do. There is more missing here, but the responses so far don’t make me think it is especially worthwhile to bring it up.
Please share the plugin you build with the community here in the plugin category, not everyone agree with every decision we make, I totally respect diversity and options, maybe others are interested in stricter password rules.