[Xylakant]

Many services let you sign up with an existing email and just send a “you tried to sign up, but you seem to have an address already.” to the account owner. In that case it’s indistinguishable for the attacker.

Many services already require email confirmation to finalize the signup process so the extra effort is low.

[wongarsu]

And those services also plug the forgotten-password information leak by just informing you "if you have an account, you got an email" instead of giving you an explicit success or error message.

I guess the better point for the article would be "many websites cargo-cult the login error message without understanding why it's there and how that should impact the rest of the service"

[asddubs]

sounds like a nightmare for someone who forgot their password and has multiple emails, and isn't sure which one is right. did i use the wrong email, did it land in the spam folder, or did my email provider just quietly delete the email (which unfortunately does happen, and not just with dodgy emails/IPs)

[Xylakant]

I have multiple emails, and this never turned out to be an issue - worst case i just try all of them.

But if you want to improve the implementation, the provide can also decide to send an email in case no account is registered with that email address - "Hey, someone tried a password reset for this email, but there's no associated account. If it was you, ..., if not, ignore this email."

[prmph]

> And those services also plug the forgotten-password information leak by just informing you "if you have an account, you got an email" instead of giving you an explicit success or error message.

This might be a better approach, but one problem I see with it is: what if the email is not actually delivered because of an internal bug in the website? How would users know they didn't receive an email they were supposed to have received, and take the appropriate action (trying again or contacting help), versus that they entered a wrong or unregistered email?

[SoftTalker]

Email might not be delivered for many reasons that may not all be in control of the sender. It may be classified as spam somewhere along the way. It may simply drop into a black hole. Eventually the user will try again.

[Thorrez]

That same problem can happen regardless of whether the password reset flow checks for user existence before sending the email.

[pmontra]

Those sites probably prompt the attacker with a "We have sent you an email with an activation link" and the owner receives the "you tried to sign up, but you seem to have an address already" message. In this way they don't leak anything to the attacker.

By the way, I've been stuck for years with an ecommerce site that thinks I already registered with them using my email. They're telling me that I must activate the account. I click the link to send me the activation message again but then they say that my email is not registered with them. I'm still stuck and will probably never buy from them because I can't.

[ohbtvz]

I'm confused, you've been trying to buy an item from that website for years and it never occurred to you to just use a different email address? This isn't really believable.

[pmontra]

I just drive to the shop.

[prmph]

With this approach, I imagine slightly less technically savvy users might be confused as to whether a new account was actually created before they were also informed of the old account. In other words, they might not know if a new password they entered is also usable for the original account.

[darkwater]

Off the top of my head, I cannot remember any site I use that works that way (which is also basically what TFA is suggesting to do as a trade-off implementation)