Feature Request: Better entropy exclusion patterns

[rbailey-godaddy]

Feature Request

Is your feature request related to a problem? Please describe.

Presently, we are trying to steer people towards exclusion patterns like uses:(.*)@[a-zA-Z0-9]{40}$ -- however, that may inadvertently mask actual violations, such as this input sequence:

...and to ensure access to our super-secret base, we have these password hashes.
The client uses: somesecrethash - last updated by @my-exactly-40-character-username

Describe the solution you'd like

In order to avoid this, it would be ideal to represent a the position of the high-entropy string in the regular expression, probably without knowing its actual identity. For example, suppose MATCH is used to represent the matching high-entropy string; the above exclusion pattern could be written as uses:(.*)@MATCH$

This allows the offending string to be more precisely described in context, ensuring that the exclusion pattern matches desired problematic-but-okay input while NOT matching other input that is problematic but not in a way anticipated by the rule. It also relieves the user of the necessity of being able to specify a RE that matches the high-entropy string.

Describe alternatives you've considered

It probably is possible to use existing functionality and write the expressions so they are incapable of matching the wrong thing -- by avoiding use of .* most likely - but this is awkward and requires a good deal of attention on the behalf of the user.

The example here (using MATCH) is not great in that it's necessary to extend RE processing.

Teachability, Documentation, Adoption, Migration Strategy

See above for one example. Nobody would have to use this strategy if they didn't want to do so. The trick is merely to identify how "the high-entropy string" is represented in the regular expression, and then explaining this with one or two examples. Famous last words.