What is a one sentence summary of your feature request?
Regex rule for password enforcement, primarily to prevent users from performing character insertion
Please describe your idea in detail. What is your problem, why do you feel this idea is the best solution, etc.
We would like the banned words feature to still block the word where the characters are not contiguous, possibly with configurable limit on the number of inserted characters in the banned word. i.e. if “password” is blocked and 2 characters max was set pass21word would be blocked but pass392word would be allowed.
a more advanced option and probably the more preferable for us would be to have banned regex expressions as well as banned words.
an example expression:
(?i)[p].{0,2}[a@4].{0,2}[s$5].{0,2}[s$5].{0,2}[w].{0,2}[o0].{0,2}[r].{0,2}[d]
this would match: p–4–s–S–w–0–r–d
There may be more elegant ways of writing the expression but this is the general idea.
How do you currently solve the challenges you have by not having this feature?
We don’t, but a large number of weak passwords have come back on our latest penetration test and has highlighted users are circumnavigating the blocked word rule by adding characters in the middle of a banned word i.e. Pass9word
This functionality works well for character substitution but does not account for character insertion. For example, if “password” is configured as a blocked word with the default substitution detection enabled, “p455w0rd” would be blocked, whereas “pass2word” would not. To prevent this, you would need to block both “pass” and “word” separately. However, I would be concerned about how short blocked words can be made, as reducing their length increases the likelihood of unintentionally restricting a large number of legitimate password options.
A useful enhancement would be the addition of a character insertion option within the blocked words configuration, allowing administrators to specify a configurable number of additional characters that can appear within a blocked term. This could work alongside the existing substitution and reverse-matching options. The result would be that passwords containing a banned word in the correct sequence, even when obfuscated with additional inserted characters, would still be blocked.
For example, “p4552word” would be denied because it still contains the entirety of the banned word “password”, with character substitutions and an inserted character.
I believe this would be relatively straightforward to implement, as the current substitution functionality is likely already based on regular expression matching or a similar pattern-matching approach.
A further enhancement would be to provide an advanced option allowing administrators to define their own custom regular expressions. This would create a highly configurable and flexible password enforcement engine. Naturally, appropriate warnings and guidance should be included to ensure expressions are thoroughly tested before being applied in production environments.
