How about improving the copy here to include something like:
“Are you sure this is the email address you registered here with? Do you have another email address you could try? If you do not receive an email from us in the next few minutes, there is a big chance you used another email address to register here. Try another email address.”
The way I see it, the problem isn’t that the user can’t remember which email address they used to sign up. It’s that they don’t come to think they have other email addresses as well. People just don’t like to admit they were wrong, even to them selves. There’s nothing wrong with just typing all your addresses there and see in which mailbox comes, but you don’t see people doing that. We need a bit of encouragement to do that.
@amyehawthorne we have had a bit of a change of heart on this. While the general philosophy is we like to ship Discourse as safe and secure as possible, in this specific case we think we should optimize for reducing the most common support requests over security.
So, @sam is going to make it so that the password reset will tell you if no email or username exists by default.
There will be a site setting to disable this behavior and opt in to the previous more secure behavior where we don’t tell you if the account or email exists, and “pretend” to send an email.
Is that the safer default though? I would have thought it would be better to have it disabled by default and let those who want to reduce their security enable it.
That seems to be true for username, the “inline” verification for email address doesn’t seem to mind if the email is already in use. When you click create new account, then it errors indicating the email address.
To turn this off, set forgot password strict to true. It is OFF by default for all Discourse instances, meaning, you will be told whether the given email or username exists when you attempt a password reset.
We do rate limit queries here (both per minute and per hour) so you can’t spam hundreds of email or account names to try to get lucky.
Jeff, I don’t understand why you agreed to reduce the security by default.
My understanding is that Discourse should be an open discussion platform to all kinds of websites. It is very narrow minded to think that Discourse users will probably not bother if their identity can be disclosed. What if I run Discourse on an HIV help website, or if I use it on a gay community website in a country where being gay is against the law? Unless you want to discriminate these websites from using Discourse, then I don’t understand why you agreed on implementing such a bad security practise - by default.
I wish Discourse would be secure by default on all pages, so I cannot disclose identities from any form, be it the password reset function, the sign up screen or anything else.
No offence, but this setting is redundant, because no one will ever use it. It is based on the assumption that most people who use an easy plug and play forum like Discourse are extremely tech-savvy people, who have plenty of security knowledge to even know about this threat, therefore will test their system against all kind of vulnerabilities, and then look for support to finally find the setting in their configuration and make their site secure.
The majority of developers don’t even fall into this category.
Anyway, I wanted to raise awareness of this problem, but after all it is your product and you choose if you target only a specific audience or if you want to make it most usable for everyone.
Sorry, one more comment on this. There is no such thing as a sensitive community. YOU might think that a Java developer site is not sensitive, but there might be plenty of reasons why it might be sensitive for an individual user. It varies per user, probably even over time in some cases.
If a website manages user data then it is in their interest to protect their users as much as possible.
How many websites use gravatar without caching … a lot … including gigantic ones, checking if an email exists on those sites does not even require a heavily throttles POST per check, you can do it in batch, heck you can brute force emails.
Are you raising your hand to support EVERY customer ever complaining about a stricter default here ?
What really gives you the right as a brand new user in this community to just step in, hijack a topic, and tell us how to do our job?
Sorry to offend you. I don’t know why I hijacked a topic and I am certainly not telling anyone to do their job. It seemed like an open thread to discuss features of Discourse and I only saw this thread recently and I had an opinion to share. You can close this thread if it is not up for discussion any more, sorry, my bad.
What difference does my registration date make? Is my opinion less welcome then? Never mind, I will not reply any more. Don’t want to cause any beef over little things.
I really just wanted to throw a wider view on this issue, because it is a well established security practise for reasons and I wanted to re-iterate it. I actually thought Discourse could be a cool tool and I wanted to share an opinion for the better.
I’m not sure if you realize that it’s rate-limited to 6 per hour. 6/hour pretty effectively cripples batching it on a giant email list.
Taken email addresses are also exposed in the create account dialog, but that has another ratelimit for “not found” results (because you end up - guess what - creating an account - which has a ratelimit.)
We aleady do something similar, point being, letting people go through the entire registration system without revealing they already have an account is insane and something I have never seen in the wild.
Name me any security vulnerability and you can find at least 10 gigantic ones, who trapped into it. Does it make it any better? (It is like a naughty kid pointing with the finger at another kid and using it as an excuse)
Look, there is never just one view on things. If my employer wants to know if I have signed up on a particular community, she will only need 1 try.
Man seriously, why are you so offended by my request to tighten security by default? I didn’t mean anything bad. You seem to take it very personal. Obviously I like your work, otherwise I wouldn’t have ended up on Discourse.org and I wouldn’t care about improving it. I shared a simple opinion on this open thread and I don’t think I said anything terribly unreasonable?
Thank you for your examples. Look, I don’t think there is a golden solution for everyone. Every product is different and requirements might be different. Facebook, Twitter and Tumblr are standalone websites whose business model is all about PI and personal data sharing. The way they handle the registration makes sense to me.
[Disclaimer - my personal assumption] Discourse on the other hand is meant to be integrated into an existing website to provide a discussion/forum tool. It can be public or private, which depends on the individual website? (If I am wrong, then sorry, feel free to correct me). So I personally wouldn’t throw it into the same pot as Twitter and Facebook.
You are all talented devs with so much more knowledge about security than the average person who will use Discourse. You know your user base better than me and if you are happy with the way it works right now, then great. I offerd you some food for thought and some constructive critique IMO. Take it or leave it, but this discussion gets out of hand now. It is really not that big of a deal.
