Password composition rules shouldn't be checked

[KamilaBorowska]

According to NIST rules:

Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets.

Those rules prevent consecutively repeated characters due to misunderstanding another requirement in NIST Password Guidelines.

When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include, but is not limited to:

• Passwords obtained from previous breach corpuses.
• Dictionary words.
• Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).
• Context-specific words, such as the name of the service, the username, and derivatives thereof.

This is about what such a list of known bad passwords may contain. aaaaaa is obviously a bad password, but say, something like Bg(=SRjSxxxx5[=thpmm?God)X~$i_[:(t44m=kF('waq7H}k8\r<]2Q]~>\($9zD<[G4Y5a,/="L`?{E]Af(;`jsk,mPk}*/y)kuZ:7ps\k{NqAb:Fx[AWL"%G92$Gk I would argue isn't insecure, even if x happens to repeat four times.

Specifically, the intent of the rule is that it should be a finite list of known insecure passwords, not a rule intending to find bad passwords (that can find an infinite number of "insecure" passwords).

[DivineOmega]

You're right.

This needs changing so we have static lists of repetitive passwords and sequential passwords. We should then modify the existing RepetitiveCharacters and SequentialCharacters rules to simply check the password against these lists, similar to how the DictionaryWords rule currently works.

[DivineOmega]

This is being addressed in PR https://github.com/langleyfoxall/laravel-nist-password-rules/pull/22.

[DivineOmega]

This is now fixed in v4.1.1.