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
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.
Wait, did I get this right that if I typed email@example.com 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 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.
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
If I enter firstname.lastname@example.org, 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
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 email@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:
Go to any website on the web that you are definitely not a member of. Let’s call it zombo.com
Imagine that you have an imaginary account there (you don’t, but you think you do).
Now enter your email address in the password recovery form firstname.lastname@example.org.
Let’s say I signed up for an airmiles program with email@example.com, but I haven’t flown that airline in 15 months, so when I come back to sign in, I assume I probably used firstname.lastname@example.org and enter that as the username with whatever I think my password is.
I expect to see “No account matches email@example.com” not “If an account matches firstname.lastname@example.org, 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 email@example.com instead, but we’ve found our user base doesn’t necessarily follow that logic.
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.
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.