Auth0 Home Blog Docs

Password reset ignores password strength and length

Hello. My issue is that it doesent seem like the password reset page has any validation.
When i go in and reset the password, both with my user and our test users that are not admin we can set the password to ANYTHING. 3 letters small characters. And we have set the password policy to Good.

This is a potential security hole.

( I am sorry, I am not sure what category to put this in. I choose the auth0.js because we call the reset password function from there. )

FYI
I looked through various guides, like this one: https://auth0.com/docs/connections/database/password-strength
And made sure the correct password policy was set as well as the library version is correct. (1.5.1) and the dictionary with “password_complexity_options” is identical

We use custom domain and hosted reset password page. I.e we call the endpoint from javascript (webauth change password) and then the user is sent to the hosted reset page.

I know password policies works for the sign up process because we just implemented our own custom UI using the javascript SDK. And i got correct errors before adding any javascript validation. I.e password to short, to weak etc from your servers.

Hi @Enin, I’ve been unable to reproduce this behaviour on my end. One thing to check is if you have multiple database connections enabled - when requesting the password reset, ensure that it is being requested for a user in the connection with the Password Strength policy applied.

It would also be worth checking if you have customized the password reset page, which could be affecting the password policy validation in the widget.

We have only one database connection. We have changed the template, but only to change CSS.

We had the very same problem. We fixed it by changing the {{password_policy}} string to the strenght name of our policy. Example: policy is of strength good we changed it to good instead of {{password_policy}}.

We know that it says DO NOT CHANGE, but this change did solve our problem.

If there is another solution to this problem where we don’t have to change the {{passowrd_policy}} part, we would love to hear that.