Auth0 Home Blog Docs

auth0.changePassword always returns OK even when user is not found

auth0js
change-password
#1

Both SDK method auth0.changePassword and Postman request to:
https://***.auth0.com/dbconnections/change_password
with body:
{
“client_id”:"***",
“connection”:"***",
“email”:"***@gmail.com"
}

always return successful message: We’ve just sent you an email to reset your password.
On the other hand in Logs I see that there was an error and mail actually wasn’t sent:
Type: Failed Change Password.
Description: User does not exist.

What can I do to distinguish in frontend side between successful and failed password reset?

1 Like
#3

Hey @mdahan

As it has been more than a few months since this topic was opened and there has been no reply or further information provided from the community as to the existence of the issue we would like to check if you are still facing the described challenge?

We are more than happy to assist in any way! If the issue is still out there please let us know so we can create a new thread for better visibility, otherwise we’ll close this one in week’s time.

Thank you!

closed #4

This topic was automatically closed 6 days after the last reply. New replies are no longer allowed.

opened #5
#6

Reopened topic per @holger request who is exhibiting the same issue.

#7

Using the Auth0 SDK for Web reference for changing password for a user: https://auth0.com/docs/libraries/auth0js/v9#password-reset-requests

The following example requests a password change for a non-existent user (example@example.com) is not a known email address to our auth0 domain. Looks like this:

Request:

fetch('https://merittian.auth0.com/dbconnections/change_password', {
  credentials: 'omit',
  headers: {
    'auth0-client': '***',  
    'content-type': 'application/json',
  },
  referrer: 'https://apply.merittian.com/reset',
  referrerPolicy: 'no-referrer-when-downgrade',
  body: {
    client_id: '***',
    email: 'example@example.com',
    connection: 'Username-Password-Authentication',
  },
  method: 'POST',
  mode: 'cors',
});

Response:

Status Code: 200
Response: We've just sent you an email to reset your password.

Auth0 Logs (Failed Change Password Request):

{
  "date": "2019-03-12T20:35:24.284Z",
  "type": "fcpr",
  "description": "User does not", // this is the response I expected with whatever appropriate status code
  "connection": "Username-Password-Authentication",
  "connection_id": "***",
  "client_id": "***",
  "client_name": "Merittian",
  "ip": "***",
  "user_agent": "Other 0.0.0 / Other 0.0.0",
  "details": {
    "body": {
      "tenant": "merittian",
      "client_id": "***",
      "connection": "Username-Password-Authentication",
      "email": "example@example.com",
      "verify": true,
      "debug": false
    }
  },
  "user_id": "",
  "user_name": "example@example.com",
  "strategy": "auth0",
  "strategy_type": "database",
  "log_id": "***",
  "isMobile": false
}

#8

After talking with our team, this is indeed working as intended. This is setup for security purposes so people don’t just brute force your user list. However if you would like to see this change please reach out to us as Auth0.com/feedback and share your use case so we can better identify how to serve you. Thanks for your patience in getting this answered.

#10

@James.Morrison – I understand the consideration. However, if I wanted to brute force my user list I could just try to sign-up, which would give my the message “The user already exists.”

What I want to achieve is to not tell a user who’s using the “forgot password” (but has no user) that I sent them an email with a link to change password, but instead force them to signup (again, because they did not have a user).

I guess I could hack it by trying to sign up the user first, which would either be rejected if user already exist or created it if not, and then after request a password change. That just seems like a misuse of the apis and counterproductive to the brute-force argument.

closed #11

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.