I have configured my tenant to enforce “Password Dictionary” protection. I have not added any custom entries so I am relying on the default Auth0 dictionary for enforcement.
The issue I’m running into is that I’m able to successfully execute a reset password flow for a user with the following password: “password1!”
With my understanding of the documentation, this shouldn’t be allowed using “Password Dictionary” enforcement. All other aspects of the password policy appear to be enforced (complexity rules, re-using a password, etc…)
Please let me know if I’m missing something with this feature, thank you!
The dictionary contains password1 but it uses an exact match so password1! would be allowed unless you add it manually to the “Additional Dictionary Entries”. Our product team is aware that there is demand for improvement here to disallow words that are “slightly” different to dictionary entries possibly via a fuzzy search for similar strings but this is still currently under review.
My team would welcome that feature as our system got dinged by our pen tester for allowing such passwords as “Password1!”. Although it met our complexity requirements, it is still a very easy password to guess. I was looking at Auth0’s Password Dictionary to help with this issue.
As it stands, an “exact match” approach makes the Password Dictionary feature not very useful. Configuring moderate complexity requirements eliminates most of the 10k common passwords from being accepted by the system.
I would be happy to submit a feature request for the Password Dictionary to apply a “fuzzy” match to passwords that contain common or easy to guess words despite meeting complexity requirements. I’m not sure how to phrase it, but setting the password to “Password1!” should be rejected because it contains the word “password” and “password” makes up 8 of the 10 letters.
Would you be able to direct me on how to submit feature requests?
This would be some excellent feedback which you can provide here https://auth0.com/feedback the product team would review and it’s possible if there’s enough demand for a feature that priorities can shift in favour of the feature so logging some feedback (your typical use case) is a good idea.
