Higher RegEx Character Limit (Current 255) -OR- Ability to Add Additional RegEx Commands (Current 1)

[Z-Brewer]

Reposting this as it's own discussion as it seems different enough from where I had originally posted it a few weeks back in:
"Add support for searching substrings of passwords #40"

Is it possible to increase the character limit for the regex portion in Group Policy so I can add it there? Or add additional fields in the entirely so that more than one Regex command can be applied?

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:

Company
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!

[ryannewington]

Hi @Z-Brewer

I'm not sure where the 255 char limit is coming from. The group policy editor has a max length of 1024 characters.

If you need more than use, the workaround I suggest is using a group policy preference registry item as shown below

Be aware that processing long regular expressions is extremely expensive. I wouldn't make a change to support more regular expressions due to this. The regular expression support is there to provide support for edge cases, not to replace the banned word list.

The banned word list on the other hand is designed to be able to have millions of entries without suffering a performance impact.

We don't cover every possible normalization scenario, that is true. However, there are an infinite number of normalization possibilities. Attackers don't have infinite processing power, so we don't need to cover every possible scenario. The LPP algorithm is based on extensive research on how password hacking tools operate, and utilizes the substitution patterns we see there, to make sure those aren't in play. Having a 'banned word' in a password is not automatically a problem. It's only a problem when the user turns it into 'c0mp4ny. Those substitutions are well known, and pose a risk. If the user were to enter 'mycompanyuseslithnetpasswordprotection" this is a really low-risk password, because no known substitution algorithms are going to guess this. A brute force is the only way this password is going to be guessed. And the words of choice when brute forcing don't matter.

However, we know having 'company' in the name is a target point, where an attacker may spend more time guessing passwords based around 'company'. This is what we see the regex for. Putting a regex of 'company' to ensure that no password can be based on 'company' (or its variants), as there are scenarios there that may not be covered by the banned word filter.

I hope that helps explain our decisions here.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs.