Improve transparency of reset password flow

[dblythy]

New Issue Checklist

• I am not disclosing a vulnerability.
• I am not just asking a question.
• I have searched through existing issues.
• I can reproduce the issue with the latest version of Parse Server.

Issue Description

As discussed here, password reset should throw with an invalid email, rather than returning success.

Steps to reproduce

Request a password reset with an invalid email.

Actual Outcome

Response is success.

Expected Outcome

Response should be "invalid email" or something useful.

Failing Test Case / Pull Request

• 🤩 I submitted a PR with a fix and a test case.
• 🧐 I submitted a PR with a failing test case.

Environment

Server

• Parse Server version: master (4.5.0)

[mtrezza]

Thanks for opening this issue.

As described in your references discussion, this change makes sense to give the developer more control over the password reset flow.

The security implication is marginal because it allows to determine whether a specific email address is assigned to a user, but that is also possible via the sign-up endpoint.

However, since obfuscation is also a security strategy, there is a security implication which has to be considered and mentioned in the changelog as a significant change.

In addition, it is a breaking change if instead of success an error response is returned in some cases. According to our deprecation policy this change should be phased in.

[dblythy]

Ok. Sounds good. How should we go about depreciating it? Add a warning and then remove it at a later date?

Also, do you think we could have a Parse Server option called deprecations, where all the deprecated options are set? Otherwise the docs for server options will become full with deprecated options.

[mtrezza]

We would add a new parse server option where the developer can choose whether the endpoint should return an error or success if the email doesn't exist.

The default would be to return success (as it currently does), with a deprecation log if the option is not manually set return an error.

Instead of deprecating we could also make it a permanent option, without deprecation. So we keep the obfuscating default setting to return success. If a developer wants to build a custom flow, they can choose to set it to return an error. The benefit would be that it's no breaking change, no deprecation needed, while keeping the more secure obfuscation behavior as default.

[dblythy]

Right, so rather than deprecating the current flow, we could add a passwordPolicy.validateEmails option or something, that defaults to false?

[mtrezza]

Yes, what do you think?

[dblythy]

Sounds like an elegant solution. Thanks for the discussion! I'll work on it.

[parse-github-assistant]

Thanks for opening this issue!

• 🚀 You can help us to fix this issue faster by opening a pull request with a failing test. See our Contribution Guide for how to make a pull request, or read our New Contributor's Guide if this is your first time contributing.

[mtrezza]

I've removed this from Parse Server 6 release list as it's not a breaking change anymore, see #7551 (review).

[parseplatformorg]

🎉 This change has been released in version 6.0.0-alpha.34

[parseplatformorg]

🎉 This change has been released in version 6.1.0-beta.1

[parseplatformorg]

🎉 This change has been released in version 6.1.0-alpha.1

[parseplatformorg]

🎉 This change has been released in version 6.1.0