Password reset error messages allow user enumeration

[pl4g4]

Could error messages can be more generic for password reset?

This is not a critical/high request, but should be taken into consideration.

I found the errors after resetting password are not generic and someone could enumerate user accounts.

Reset password SSO

An invalid user account returns this msg

https://github.com/kolide/fleet/blob/06832697d0e6ed6b2ca0220ef5434791db7b0a27/server/datastore/mysql/errors.go#L23

A valid user account will return this msg

https://github.com/kolide/fleet/blob/45f6a74740af83390b93ca6f7e347bd8decf37e0/server/service/service_users.go#L243

It could be something like

"If you have an account, a password reset email will be sent" Or something more generic.

thanks!

[zwass]

This is something that has been brought up in the past and determined that the UX is worth it for the possible enumeration.

If additional folks think this ought to be changed, I am willing to change it.

[margaretho]

I don't think there need to be trade-offs for UX vs. security. Error messages can be made more generic to prevent user enumeration while also providing a good user experience. A similar discrepancy in error messages occurs on login: when an organization requires SSO, attempting to log in with a password results in the following error for a valid user: "password login not allowed for single sign on users", while attempting to log in with an invalid username results in a different error: "username or email and password do not match". A message of "The credentials provided were invalid. If you are a single sign-on user, please log in through your SSO provider." sent to all users in all cases would be completely reasonable, in my opinion. I'm happy to put in a PR for this change if you all are amenable.

[zwass]

The tradeoff is this:

Downside - User enumeration is possible. Upside - Legitimate users can get some information to help them understand why their login failed.

For folks who are especially concerned about this, a mitigation is to only expose the admin interface behind a VPN. This is actually a very common deployment strategy for Fleet.

Fleet does not phone home or provide any analytics that would help to understand how this plays out in real world deployments.

I remain open to changing the functionality if we can get more engagement on this issue and the community seems well aligned.