Maybe there is a way for us to improve the performance of an unmungger.
The main problem is, that the new improved l33t matcher is going through every possibile version of a "cleaned" or partial cleaned string. For example P4$$w0rd -> P4$$word -> P4$sw0rd -> P4s$w0rd and so on.
Additionally every possible substituion is going triggering zxcvbn-ts again to check for matches.
One easy part to fix it is to limit the number of substitution to check against. In the documentation it is written that the l33tMaxSubstitutions is 100 but in the code its still 512. So we should go down to 100 in the code too.
An improvement could be to split the subs into chunks and do the checks in parallel.
I think the l33t matcher is used in the sub zxcvbn-ts calls too. . This could be canceled as we already doing this because we already have every expected substitution at hand. But this need to be checked
The new unmungger in the l33t matcher is dropping the performance significantly for a lot of special characters like a repeated
!https://github.com/zxcvbn-ts/zxcvbn/issues/31#issuecomment-1656377005 https://github.com/zxcvbn-ts/zxcvbn/issues/31#issuecomment-1673944116
Maybe there is a way for us to improve the performance of an unmungger.
The main problem is, that the new improved l33t matcher is going through every possibile version of a "cleaned" or partial cleaned string. For example
P4$$w0rd->P4$$word->P4$sw0rd->P4s$w0rdand so on. Additionally every possible substituion is going triggering zxcvbn-ts again to check for matches.One easy part to fix it is to limit the number of substitution to check against. In the documentation it is written that the
l33tMaxSubstitutionsis 100 but in the code its still 512. So we should go down to 100 in the code too.An improvement could be to split the subs into chunks and do the checks in parallel. I think the l33t matcher is used in the sub zxcvbn-ts calls too. . This could be canceled as we already doing this because we already have every expected substitution at hand. But this need to be checked