FYI: In the Best Practices badge app, we no longer reveal if a local email address exists when someone tries to create a local account

David A. Wheeler


In the Best Practices badge application ("BadgeApp"), we no longer reveal
if a local email address exists when someone tries to create a local account.

Details below. Thanks!

--- David A. Wheeler


The Best Practices badge application ("BadgeApp") does not publicly reveal email addresses.
We even encrypt email addresses in our internal database, to give them extra protection.
That applies to both GitHub accounts and to "local" accounts (accounts local to the BadgeApp).

However, before today, if someone tried to create a new local account
using an email address of an existing local account, the BadgeApp would reveal if the
email address was already in use by a local account. I don't think this was a *serious*
problem: our rate limits would have made this hard for attackers to use,
we didn't reveal which account matched,
it didn't apply to GitHub accounts, and *many* sites give similar messages
"sorry that email address is in use" - so for many this is expected behavior.
More generally, attackers would already have to know about (or at least suspect)
the specific email account before they could ask the question, making it
a lot less useful to attackers.
Still, we try very hard to not reveal *anything* we don't have to, so we've
recently changed things to prevent it.

Now, if you try to create a local account, it'll just tell you to look at your email.
If the account didn't exist, it'll create it & send an activation email as usual.
If the account was created but not activated, it'll resend an activation email (maybe it got lost).
If the account is fine, it'll quietly do nothing at all (so we won't be a way to annoy existing users).
However, all of this is only visible (or not) to the one who can access the email account.
We continue to delay activation and first login for local users, as that is
remarkably effective at countering spammers.

If people think this is a good general policy, we could add something about
it to the "fundamentals" course on security.