The discussion revolves around the password reset process in Discourse, specifically the message displayed when a user enters a valid or invalid username/email. Initially, the system responds with the same message regardless of whether the account exists, for security reasons.
amyehawthorne suggests that this approach can be confusing for non-technical users who may not understand why they don’t receive an email and may contact the site admin for assistance. codinghorror argues that revealing whether an email has an account on the site or not is a security issue, as it can be used for username enumeration and social engineering.
However, after further discussion, the team decides to optimize for reducing support requests over security in this specific case. codinghorror announces that the password reset process will be changed to inform users if no email or username exists by default, with a site setting to opt-in to the previous more secure behavior.
The conversation then shifts to the sign-up process, where sam suggests that instead of showing an error message when a user tries to create an account with an email that is already in use, the system should pretend to send an activation email but do nothing. This approach is deemed secure by default.
However, sam later discovers that popular sites like Tumblr, Twitter, and Facebook disclose email addresses in use, making this approach not as secure as initially thought.
The team decides to use the existing forgot password strict setting to also work on account creation and rename it to “do not disclose email addresses in use” as suggested by michaeld. When someone signs up with an email that has already been taken, the system will respond as if the signup was successful and send an email to the email address suggesting they change their password, similar to Hipchat’s approach.
neil partially implements this change, but notes that the “account created” page doesn’t show the necessary buttons to maintain the illusion, and the setting is renamed to hide email address taken. The change email form in user preferences is also updated to respond as if it was successful and send an email to the owner of the other account.
In the password reset process, you receive the same “You might receive an email shortly” message whether you have entered a valid username/email or not.
While I can see the security value of not giving an indication of which logins exist and which don’t, it’s a little confusing to the non tech-savvy end user who isn’t going to logic through the situation when they don’t receive an email and is just going to contact the site admin saying it’s broken
That’s not the exact text though, what we say is:
If an account matches the username xaswae, you should receive an email with instructions on how to reset your password shortly.
and
If an account matches name@example.com, you should receive an email with instructions on how to reset your password shortly.
This seems reasonably clear to me, the only alternative is to allow a bit of a security hole where you can type emails and usernames to see which exist.
FWIW, while Amy phrased this as a hypothetical, this is exactly what happened today.
We’ll keep an eye out for more cases and let you know if it continues to be a problem with our users.
This is covered here:
You see that [screenshot of a porn site]? Focus now – we’re looking at the message which says “There is no user registered with this email address”. The problem, of course, is when a site like this confirms there is a user registered with that email address. Bingo – you’ve just uncovered your husband’s / boss’s / neighbour’s porn fetish!
Of course porn is a bit of a canonical example of where privacy is important, but the risk of matching an individual to a particular website goes beyond a potentially embarrassing disclosure such as this. One risk that arises is one of social engineering; once an attacker can match a person to a service, they have a piece of information that they can begin leveraging. For example, they may contact the individual whilst posing as a representative of the website and ask for additional information in a spearphishing attack.
This practice also opens up the risk of “username enumeration” where an entire collection of usernames or email addresses can be validated for existence on the website simply by batching requests and looking at the responses. Got a list of everyone’s email address from the office and a few spare minutes to do some scripting? You can see the problem!
The alternative he proposes is sending an email to the “bad” or “incorrect” address, (assuming the user entered an email..) letting them know that the email has no account on the site.
This means you have to severely rate limit the password reset dialog, which we may want to do anyway.
In general, Discourse needs to default to the more secure / safe defaults for the betterment of the Internet.
I understand the reasoning, though I’d be more worried about someone then writing a script to try and figure out a user’s password than that someone would find out who has an account on a software support forum (what we use Discourse for). And that can be circumvented by a bad password lockout.
And, as Dave points out, we’ve already had a real world case of this.
I am open to a site setting here, also we really should ask what the folks at http://security.stackexchange.com think about our predicament and the default.
I do want to do this, but it will be a post V1 thing.
As we are sending emails to potentially random email addresses at this point, additional security measures needed:
Limit to one email notification per day per username@example.com email address
Limit to (n) email notifications per day per IP address
CAPTCHA on the form to prevent bots
@sam also wants it to be behind a default off system toggle, I can see that.
Not entirely sure how we can handle potential Tor (random IP) exploits here, perhaps ignore them for now?
Wouldn’t one solution be: Show them what they entered…
An email will be sent shortly to ______
That way, if they see they mistyped their username or email, it becomes obvious that the email will never be received and you don’t have to identify if the user/email exists.
We already do this. Try it yourself. Per the earlier posts, people don’t think it is enough.
Additionally some people “think” they signed up but either have not, or did so under completely different email addresses.
Wait, did I get this right that if I typed not-a-discourse-user@someonesdomain.org in the password recovery form, it would actually send an email to that address even tho no such user exists?
Aside from being a horrible idea in its own right, this could even get Discourse site operators into trouble. I reeeally hate to bring this up, but EU laws would classify this as unsolicited advertising and allow sleazy lawyers to squeeze a few hundred €s out of the admin. 
I do not think a forgotten password reset can rationally be considered unsolicited advertising.
The support problem is that some users forget everything, including what email they used to sign up.
Per Troy Hunt: Everything you ever wanted to know about building a secure password reset feature
I remember having read an article describing how a user had been sent a confirmation email for a newsletter subscription even tho they had never done business with the sender of the newsletter and hadn’t initiated the subscription and that, ridiculously, some judge actually considered this an unsolicited mailing.
Unfortunately, I can’t find a source now. 
Exactly. I think in our case, the user had used the Google OAuth initially, which was their private email account, but then tried to log in the next day with their work email (since we are B-to-B, so I, for example, only use my work email address when signing up for any work-related service)
I totally get that, and I think the system-wide toggle might resolve this. For more “public” discourse forums, you could toggle to the current behavior. For more private ones, like ours, which is a B-to-B customer support forum, you can turn it on.
My desired ideal behavior does not send an email to any email address you enter, it does this
This is pretty standard behavior for all the other web services I use, so I don’t think it would shock or anger most users of any given forum
First of all, let’s be 100% rock solid clear that we already say
if an account exists for name@example.com we will send a password recovery email.
paraphrasing here, but you see what I mean. We confirm the typing of the email that the user told us they think has an account, by simply echoing it back to them.
I don’t think sending an email to completely unknown users on the premise that it is a user who has forgotten which email they used is “pretty standard behavior” – this is really hard to get right, which is why very few services even try to do it. I dare say it’s actually rather risky.
To test this hypothesis, do this:
zombo.comname@example.com.Do you get an email form that says
To: name@example.com
From: zombo.comOoops! Someone thinks name@example.com has an account on zombo.com. We have no record of such an account. If this is not you, you can safely ignore this email.
I’d wager on 9 out of 10 (or more) websites you tried to do that on, you would NOT get this email.
I just did this on nytimes.com for example and I got:
We’ve sent an email to name@example.com. If this is not the email address associated with your account, click here to resubmit the “Reset Your Password” request with the correct email address.
I have no account, and I used my real email address. No actual email arrived at my account…
Ah, I somehow missed that in the reading. I thought a generic message was being shown that didn’t indicate what was entered, and by indicating what was entered may help resolve the issues.
I’m sorry if I’m being unclear, but that’s not at all what I’m requesting.
Let me start all over and use an example from non-discourse world that is the behavior I’ve come to expect from any website with a signup/login.
I have two email addresses:
Let’s say I signed up for an airmiles program with myrealemail@domain.com, but I haven’t flown that airline in 15 months, so when I come back to sign in, I assume I probably used mysignupaccount@domain.com and enter that as the username with whatever I think my password is.
I expect to see “No account matches mysignupaccount@domain.com” not “If an account matches mysignupaccount@domain.com, you should receive an email with instructions on how to reset your password shortly.” (what discourse does) Granted, I would see that, wait 15 minutes, get no email and try myrealemail@domain.com instead, but we’ve found our user base doesn’t necessarily follow that logic.
And following the logic I laid out:
If I enter mywrongemailaddress@domain.com, it displays an error message “No such user found” and no email is sent
If I enter mybuddysemailimtryingtoprank@domain.com who is not a user, it displays an error message “No such user found” and no email is sent
If I enter myemailaddress@domain.com, I get the reset message
If I enter guysemailisomehowfiguredoutalsousesthisforum@domain.com, he gets the “You (or someone else)” message and ignores it - and I think the limiting rules outlined above cover that scenario well to avoid obnoxious abuse and the user receiving the erroneous email is already signed up for that specific forum, so it’s not an unsolicited alien service
If I enter name@example.com on zombo.com, that falls into “If I enter mybuddysemailimtryingtoprank@domain.com who is not a user, it displays an error message “No such user found” and no email is sent”
Nobody gets an email unless they are a user, the thing I’m trying to shore up is clarifying for people who don’t receive an email that it’s because they entered the wrong thing, not because the site went down or it’s lost in their junk folder or something.
So you’re saying in addition to the “you might” it should also have something like “if the email address is correct” to clue in those that don’t also have your logic?
Exactly, it’s just the ambiguous “IF” that’s tripping up our people
This goes full circle: what you’re asking for is a fundamental security issue. Sites should not reveal whether an email has an account on that site or not at the time of “forgot password” – you could just type in a bunch of addresses (or write a script to do it much faster than a human would) and boom, you now have a list of valid email accounts on that site.