-
Notifications
You must be signed in to change notification settings - Fork 189
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Complexify bans passwords containing banned words #31
Comments
I think this is an error in the documentation. It would make no sense to have the banned password check reject parts of the actually banned passwords. If this was the case a password of "45ss6gt7" would be banned because the banned password of "password" has "ss" in it. Strict mode actually rejects passwords if they used in a substring of the password in addition to the exact match ban. An example of a rejection in strict mode would be the password "strong456password!" because the banned password "password" is a substring of it. |
Not sure if we understand each other / the docs correctly. What I think you are saying is that a password would be rejected if it contains a part of a banned password (so pwd contains substring of banned) What I read in the docs is that if the password is a substring of a banned password it would be rejected: So, given banlist = ['password']
Now I can see why you would say that However, personally I think it's strange. It makes the banlist unusable as far as I'm concerned. Especially with shorter banned strings it gives a lot of banned combinations. Many of which will be impossible to explain to users. Looking at the example I gave I think it's really weird that typing that extra With the current behavior having short passwords in the banlist will give you lots of rejections. And having this banlist:
Would make it impossible to create any password with any lowercase letter in it.... The behavior as documented does make a lot of sense to me. Of course if
It ends with In my humble opinion, the docs are (should be) correct and the current behavior of complexify should be changed to match the docs. At least that would make the banlist usable for me. If you change the docs to match the current behavior, then the specified behavior becomes much, much more strict. And as such not usable for me any more as I want to sign-up process to be simple and painless for my users. |
I opened issues in the projects of the different ports of complexify to request feedback on whether they think the docs are correct or the current behavior. |
Have you tried loose mode? It only matches banned passwords exactly. Loose mode is what I ended up with on my websites because I didn't like the way strict matching worked either. -----Original Message----- It would make no sense to have the banned password check reject parts of the actually banned passwords. If this was the case a password of "45ss6gt7" would be banned because the banned password of "password" has "ss" in it. |
Yes, |
Hey everyone. Thanks @Download for opening the issue.
This is correct. It is the expected behaviour of "strict" mode. This was intended to prevent users using passwords like "password123", even if it didn't specifically appear in the banned password list.
This is a bug in the documentation. I will try and get a fix out for it soon. |
I believe the way @Download interprets the docs is correct, and the functionality should match. He is entirely correct that banning shorter passwords would make very strong passwords fail. I have used this tool set before in a loose fashion and not run into this issue. I am going to start a roll out with strict on, and will edit the complexity measure to function the way @Download suggests. |
I agree. @danpalmer is 'the boss' so it's his call. But I strongly feel that the docs are right and the implementation wrong.
I understand why this would be desirable and if you write it down like this it seems to make sense. However, you did not address my concern: having this banlist:
Would make it impossible to create any password with any lowercase letter in it.... This cannot be the intended behavior right?? However it is what will happen if you try to prevent users from adding extra characters to banned words, you will ban all combinations containing a banned sequence. Hence, using short sequences in the banlist makes it very strict for users. I feel the banlist is especially useful to guard against short, unsafe sequences. This password is relatively safe, even though it is very short, because it uses characters from many different character groups:
This password however, is very unsafe:
Not only does it hardly use any different character groups, it's also a common word. So yes we want to ban this. However, make the passwords longer and the importance of using different character groups fades. It's actually a very valid strategy to use long passwords that are combinations of common words. They are more easy to remember and are generally stronger than short passwords, even if they don't contain characters from many different character groups. Please have a look at this cartoon which explains it perfectly well imo: https://xkcd.com/936/ Personally I use the shorter, complex passwords... Because I am lazy and don't want to type much. But that's a personal choice. Others may very well use the long ones. I don't want my software to force that choice on users. That's why I allow for very long passwords as well as short ones. Also I don't force the user to use e.g. numerals or punctuation marks. I do however demand from them that the password has a minimal complexity. Hate punctuation? Use a long password. Hate typing? Use numerals and punctuation symbols. The choice is yours. However, the complexity algorithm fails to account for common words. It ranks
as being equally complex as
Which to us as humans is not correct. This is where the banlist comes in. It allows us to make sure that short passwords are not too easy, by preventing common words, ideally, we would simply ban all common words shorter than, say. 10 characters. Making it also ban substrings of banned passwords helps in this respect. Preventing However, the banlist as it currently is (in strict mode) prevents the use of long passwords that are common word combinations. Even though these are not only perfectly safe (often safer than cryptic short passwords) but actually recommended by many. If you insist on changing the spec to match the code (a mistake imho), then at least put some bounds on it. So that if the password length (or complexity perhaps?) becomes greater than some threshold, it stops banning. The current behavior just feels so wrong! Please have a look at my example passwords which are outrageously long and complex but will still be banned... |
Sorry for the long rant :) but I still have something to add. For me the rule should be this:
The current behavior of
as stronger than
even though it's shorter. It means a user will see the bar indicating his password strength going up with each keystroke as he types this, only to suddenly fall to 0 as he types the last Please reconsider Dan. |
I ended up using https://github.com/dropbox/zxcvbn |
Please go to the complexify homepage and type in this password:
Id0ntTh!nkTh1sB4gSh04ldGet4Fr33Pass
Notice how its complexity is 0%.
Now remove the last letter:
Id0ntTh!nkTh1sB4gSh04ldGet4Fr33Pas
Notice how its complexity is now 100%.
The docs on
banMode
state that:banMode
:Either:
My password is not in the banned list, nor is it a substring of any item in the banned list. It contains an item from the banned list, but as I read the docs that should be ok?
The text was updated successfully, but these errors were encountered: