How to handle password reset requests for emails that do not exist?

[maxachis]

Context

When password requests are made for emails which do not exist, one of two things tend to happen:

1. The system informs the user that such an email does not exist, or
2. The system informs the user that, if an email exists, a request will be sent.

Requirements

• Determine which of the two options we want
• Then, implement that logic

Tests

• Tests will need added for the new logic

Docs

• API documentation may need updating

Open questions

• See above.

[josh-chamberlain]

I much prefer the first option; "if an email exists, we will send it" has always left me wondering if i typed my email correctly or remembered which one I used to sign up. If possible, we should check, then tell them whether we sent the thing or not.

[maxachis]

@josh-chamberlain So while that would be relatively simple to implement, I would point out (and note I failed to do so prior) that disclosing which usernames we have makes it easier for gremlins to perform user enumeration attacks, AKA submitting requests to determine whether specific users do or do not exist on the system. The typical recommendation is to obscure information about whether or not a username exists.

Of course, this article points out that this isn't a high risk for many consumer applications where the information that can potentially be exposed isn't high. And most places already allow for user enumeration through their sign-up pages -- most places won't allow you to sign up with a user email which already exists, and indeed our own user signup logic does this as well.

I want to make sure that's all brought to your attention, and will then defer to whether you want to stick with "Tell them we sent it" or go to "Maybe we did or maybe we didn't send it, tee-hee."

[josh-chamberlain]

@maxachis oh, good point! That's fine, we can do the "if an email exists" message.