Add support for searching substrings of passwords

[ToxicDave]

First of all I have to say, this is one of the best Open Source programms I've seen! But something with the BannedWords bothers me.

Isn't it possible to not only normalize the password that it has to be the exact same value at the end, but also check if any BannedWord is content of a password?

That this constelation would get blocked. BannedWord: "helloworld" Password: "helloworld123abc"

When I understand right, at the moment the "abc" at the end of the password cause the problem that it can't be normalized to "helloworld"...

[dm2746374]

I'm curious about the same thing. Can the bannedwords strings be the law if they are present in any part of the password?

[Wolverine903]

Seeing similar issue. For example in attached image, Arden and Winter are both in banned word store, but a user could set their password to ArdenWinterArden5. I have also made sure the LPP Store is the correct location in the registry.

[ryannewington]

Hi all

The banned word functionality is really designed to prevent people choosing passwords based on individual words and creating easy to guess patterns based on them. The reason for this is common dictionary based attacks will know these patterns and easily guess them as part of their algorithms.

An example. If I added lithnet to the banned word list, I prevent common variations such as Lithnet2020, Lithnet123!, L!thn3t

But it is not designed to stop passwords like LithnetIsAwesome because that doesnt form part of a dictionary based attack pattern.

Internally the banned word is stored as a hash, so we can't do substrings matches on that content as we don't keep the original string.

If you have a small number of substrings you want to outright block, you could look at doing this with a regex block policy.

I can look at adding functionality for a larger number of substrings, but there would need to be a limit, as it is a much more expensive process and we need to manage performance. Can any of you give me some scenarios you want to protect from and what sort of items you'd put in your list and how many you'd think you'd need?

And thanks for the kind feedback @ToxicDave

[Wolverine903]

Thank you for the response @ryannewington

I think at this time I am good, really just wanted to see if this was by design or if there was a setup issue by me. Thank you for clarifying this.

[ToxicDave]

Thanks for the response @ryannewington

Thank you for the clarificattion and explaination. I am good with your answer too and understand, that there have to be a limitation of the program, to safe some performance.

The case I thought about would be, that this "Blacklist" would only be checked, if the password gets changed by a user. Therefore the problem of comparing 2 hashes maybe could be solved. If a list like this would exist, I would put in some strings, which wouldn't be normalized, to check the password for. I don't know how many strings I would add to a list like this.

But I will try the possible solution with regex first as I don't want to generate work for you :)

[Techie4Life83]

Regex would be nice to have in there.

[ryannewington]

Regex would be nice to have in there.

There's already support for reflex policies.

[evertonbernardi]

I don't mean to hijack this topic. Just to add my 2 cents in here:

There is another Password Filter tool made by @ryanries (https://github.com/ryanries/PassFiltEx) that does this kind of verification.

Would it be possible for you to add this feature here? It would be really awesome!

[Z-Brewer]

Is this still being considered?

If not, is it possible to increase the character limit for the regex portion in Group Policy so I can add it there? I believe the current limit to only be 255 characters which gets filled up pretty fast when trying to include a long list of words.

Example, using 2 words I don't want in a password anywhere:

1. Company
2. Industry

It then becomes this RegEx command for the corresponding Lithnet Group Policy field: .*([C(<][O0][MW3][P][A4@][NUZ^][Y4]|[IL1!][NUZ^][D0][UN4][S5$][TL17+][RN][Y4]).*

(Case insensitivity seems to automatically take affect in your tool so the syntax for that isn't needed. However, those 2 words already took up 80 characters...)

This would successfully block both words in entirety from being used anywhere in the password. It also allows the user to include their own normalization rules.

For myself, I built a PowerShell script that generates these RegEx commands where all I have to do is provide the words I want to use and it will spit out the syntax according to my normalization rules. If anyone is interested I can share it, but it's easy enough to make on your own. Just be careful not to add too many substitutions or you'll block words you didn't mean to.

This would solve the issue [and probably make the banned word list obsolete (maybe even freeing up resources? idk, I'm not a coder, just a simple scripter)].

Which brings me to my next point... This is an amazing tool and I really appreciate the work you've done to make it! So thanks!

Edit: In addition to @evertonbernardi 's comment, regex could be used to fulfill the 60% (or any %) match as well.