[rraval]

I disagree with the section titled "Username enumeration and the impact on anonymity".

The author is trying to make the point that you shouldn't tell users that their username is invalid in a password reset flow. The author then goes further and recommends obscuring error messages during the login flow as well.

I find this behaviour to be user hostile and not particularly effective at concealing anonymity. Under the same threat model, a suitably motivated third party can simply attempt to sign up with the same username, and you'll definitely have an error message if the user is already signed up (and that's besides the point that just because a username exists doesn't mean the person behind that identifier actually signed up, anyone could've done it).

The author tries to justify their position by calling it a "slight usability tax" and "a small trade-off for an infrequent process", but my very short experience building a consumer oriented SaaS is that:

1. Password requests are frequent, even with ~5k users

2. Lots of people have more than one email address, and frequently forget which one they used for your service.

3. The support burden simply isn't worth the pseudo-anonymity.

[timc3]

If the username could be an email address (or the email address is a required field on signup) you don’t have to pass back a message saying that the username is already taken. You simply let them go through the flow and do verification of the email address by emailing and requiring clicking on a link, and if they are already signed up send a message saying someone tried to sign up with your email address.

Of course if the username can’t be an email then the email address must be required for login, the username is just for display purposes.

Also when doing the password reset you don’t need to tell them their email is invalid, you just send out the email for reseting as normal but have some text at the end saying ”if this wasn’t you blah blah blah...” and ignore it if it’s an invalid email.

And of course there are ways of dealing with changing of email address.

[rraval]

> If the username could be an email address (or the email address is a required field on signup) you don’t have to pass back a message saying that the username is already taken. You simply let them go through the flow and do verification of the email address by emailing and requiring clicking on a link, and if they are already signed up send a message saying someone tried to sign up with your email address.

Sure, let's play this out. Assume for simplicity that the username / user identifier is the email address for our example.

---

Someone comes to your site and tries to sign up with `[e-mail]`. The system has never seen `[e-mail]` so:

The system registers `[e-mail]` in a pending state and sends an email link to `[e-mail]` saying "Please click this link to finish the signup flow".

It also responds to the person signing up, saying "We've sent you an email, please click the link in your inbox to finish the signup flow".

---

Someone comes to your site and tries to signup with `[e-mail]`. The system has an existing record of `[e-mail]` and the password does not match.

The system sends an email to `[e-mail]` saying that someone tried to sign up a new account with the wrong password.

It also responds to the person signing up, saying "We've sent you an email, please click the link in your inbox to finish the signup flow".

---

For a system as described, I concede that a third party has no means of checking if an email address has already signed up, the messages they receive are indistinguishable.

However, for this to work, the click-link-in-email step needs to be a synchronous part of your signup flow. I worry what this added friction does to the bounce rate. Although since I haven't measured it, maybe this worry is misplaced. And of course there's the caveat that measuring with statistically insignificant sample sizes in the early days of a product is its own can of worms.

[jdeibele]

Often the message is "If there is an account with that email, we'll send you a link". The idea is that you don't want to confirm that there is an account because it might be someone testing to see if there is one.

On the other hand, I would think that the bigger problem is people using the same password with multiple sites and the attacker is entering username/password combos as fast as they can. Joe Hacker isn't probably going to look at your Facebook page for where you went to school, what your dog's name is, etc. Unless they're after you specifically.

[PretzelFisch]

Don't most signups require clicking an activation link sent via email anyway these days?

[OliverJones]

I built a password reset system that didn't tell the requestor whether they gave an unregistered email address. It just said, "look in your mailbox." Because, avoid telling cybercreeps anything useful.

But my tech support team screamed about it. So, I changed it to send an email to the unregistered address saying

"somebody asked for a password reset to be sent to this email address. But we don't have an account associated with this address. If you need help please hit URL or call PHONE. "

A cybercreep still can't tell from the password-reset page whether the email was correct.

This ruse solved my support team's problem.

[ergothus]

> This ruse solved my support team's problem.

Having places where I don't recall if I have an account, and if I do, which of my email accounts it was registered to - this solution would actually make me happy. I recall running into it once or twice in the wild and was always just as happy to get the "we don't have an account with this email message" in either email or immediate feedback. That said, I agree with the poster that sees the actual security of hiding usernames as marginal at best, outside of sites where the mere presence of a user is indicative. ("Johnny, why do you have an account on "ILikeLeadingCommas.com"?!")

[hinkley]

I've seen variations from "look in your mailbox" to "If there is an account associated with this email address, you will receive instructions."

There are plenty of ways to be imprecise from an information asymmetry problem but still precise enough to allow someone to follow instructions.

[croisillon]

so I receive an email (possibly more than once) from [e-mail] telling me someone confessed not to know the password associated to my email address because I don't have an account there? for the email-recipient the cure might feel worse than the disease

[rhacker]

Technically there doesn't have to be live email validity checks on the sign up page- an email with the continue your signup with this link could be made available. OR an email saying you already have an account, do you need to reset your password?

[funkymike]

If you allow the full signup with the email confirmation after, then you are potentially sending the confirmation email to the wrong person. I have gotten sign up confirmations from other people using my email address. I have sometimes confirmed the registration, used the password reset to take over the account (since they use an email for the reset), then cancelled the account.

If you aren't validating the email by sending an email that has to be replied to as part of the sign-up process (not after), then you are simply assuming that the email address was entered correctly without an opportunity for the person attempting the account sign up to correct it.