Improve default privacy for email-based password reset and better document `request_token_inhibit_3pid_errors`

[fguisso]

Description:

I’ve recently been reviewing the behavior of the password reset flow in Synapse, especially in relation to how email addresses are handled during the /requestToken process.

I contacted the Element Security team to report a concern about email enumeration through this flow. They confirmed that this is a known behavior and a trade-off between usability and privacy. Based on that, I’d like to suggest some changes that could improve privacy defaults and documentation, without affecting the existing functionality for those who prefer a more user-friendly approach.

Observation

Synapse already includes the configuration setting request_token_inhibit_3pid_errors, which masks whether an email address is registered during the password reset process. This is a very effective control to avoid user enumeration, but it is:

• Disabled (false) by default,
• Buried in internal documentation,
• Not visible in initial setup instructions or sample configuration files.

Additionally, the Matrix.org team uses matrix-authentication-service, which appears to solve the problem at a different layer, by handling sensitive flows separately and privately. This could also be mentioned in the documentation for projects with higher privacy requirements.

Suggestions

1. Set request_token_inhibit_3pid_errors to true by default in new Synapse version, with an optional override for admins who prefer usability over privacy.

2. Document this setting more visibly, including:

   • A note in the main README or a dedicated "Security & Privacy Recommendations" section.
   • Inclusion in the sample config file and installation guides.

3. Clarify the role of matrix-authentication-service in solving this problem, and whether it is recommended for setups that require stricter privacy guarantees.

4. Apply similar changes to synapse-tchap and others servers if applicable, to maintain consistency across forks.

If this makes sense to the team, I’d be happy to help by submitting PRs to update the documentation and propose config defaults.

Thanks for your work on this project and for enabling open discussion around security and privacy.