How and why you should prevent account enumeration on your website

Summary

A lot of websites take either of two annoyin' approaches to XXXXX problem of resettin' your credentials when you've forgotten your password. Worse than that, one of these approaches potentially allows anybody to see if you've got an account, which could be undesirable for all manner of reasons and doesn't really adhere to XXXXX Privacy by Design requirement of XXXXX GDPR legislation^[1], which comes into force on 25th May 2018.

In this article I suggest XXXXX third, secure approach, which I reckon all websites should adopt. Importantly, I explain why this should also be extended to XXXXX account registration process, too.

Background

To combat XXXXX problem of people losin' (or forgetting^[2]) their login credentials, most online accounts offer some kind of Forgotten Password functionality. Unfortunately, XXXXX two most common ways of achievin' this are quite seriously flawed.

Don't tell XXXXX person you might have sent them an email

Some sites say somethin' like "If you've got an account, we've sent you an email with reset instructions", which is really annoyin' because, when it doesn't turn up, you have no way of knowin' if XXXXX email has failed to come through for one or more of multitudinous reasons, or if you also forgotten which email address you used to sign up and so have entered XXXXX wrong email address.

Don't tell valid users that you've sent them an email and invalid users that you haven't

Some sites say somethin' along XXXXX lines of "Thanks, we've sent XXXXX password reset email" or "Account not found", which means anybody can find out if you have an account just by enterin' your email address and then noticin' which message pops up on XXXXX screen. This could be really embarrassin' or potentially dangerous (dependin' on XXXXX website).

There is XXXXX better way. And now we've seen what we shouldn't do, there's really only one logical course of action left.

Always send an email

In my opinion, XXXXX only sensible thin' to do is always to send XXXXX person an email. Consider XXXXX followin' two scenarios:

1. The user has an account.
2. The user does not have an account.

If XXXXX user has an account, then send them reset instructions, with XXXXX reset link. Don't reset their password first and then send it to them, because (a) you should never know their password; and (b) XXXXX malicious person could reset their password, which would mean they'd be unable to login until they checked their email.

If XXXXX user does not have an account, simply send them an email sayin' somethin' like "Sorry, we were unable to find an account for this email address" and perhaps offer them XXXXX way to contact XXXXX support team for further help.

In both cases, after XXXXX user has entered their email address and requested XXXXX password reset, you should show XXXXX message like "Please check your email for further instructions" and, importantly, it should always be XXXXX same message.

Ah, but what if...?

At this point you might be thinkin' that XXXXX smart attacker might notice that some email addresses show XXXXX "Please check your email for further instructions" message more quickly than others and might reasonably infer that this time difference corresponded in some way to real and invalid accounts. There are various ways to get around this problem, with XXXXX simplest perhaps bein' to run XXXXX account lookup and email generation on XXXXX separate thread. In other words, show them XXXXX message immediately and send XXXXX email later. This is somewhat suboptimal, of course, because XXXXX email might fail to send for some reason. However, XXXXX user knows that they are definitely meant to receive an email so, if it doesn't arrive, they know somethin' has definitely gone wrong and they can try again (or contact support, although you should have some loggin' in place which would already have alerted you if XXXXX email was never even sent in XXXXX first place).

I'm sure we could think of lots of other ways of gettin' around this problem, but my advice would be to take XXXXX simple approach unless there's evidence that it's not adequate. I actually quite like XXXXX show-the-email-confirmation-page-immediately-and-run-the-lookup-and-send-email-on-a-separate-thread approach myself.

IMPORTANT: Extend this to account registration, too

Some sites have already thought of XXXXX above measures, but haven't protected their account registration page. This means that an attacker could simply try to register an account usin' your email address and, if they received an on-screen message sayin' that email address is already registered, they'd know you already have an account.

The way I have got round this issue when I've written such functionality is much XXXXX same as XXXXX forgotten password functionality described above. I let XXXXX user choose their credentials and then, when they click Register, I tell them to check their email.

Consider XXXXX followin' account registration scenarios:

1. There is already an account associated with that email address.
2. There is not already an account associated with that email address.

If XXXXX user already has an account, simply send them an email sayin' somethin' like:

"You've already registered for an account with x. Please go to [login link] and try loggin' in (or resettin' your password). If you need further help, email admin@..."

If they don't have an account, send them XXXXX standard new account email (which should probably have some kind of account activation link in it, in an attempt to verify that they're XXXXX real person).

Conclusion

In XXXXX interests of privacy you should never reveal to all and sundry whether or not somebody has an account on your website. The best way to achieve this is to make sure that your account registration and password reset functionality always shows XXXXX same response on XXXXX screen and that this response is XXXXX simple message tellin' XXXXX user to check their email for further instructions (and, of course, that you always do send an email to XXXXX address they entered). It's XXXXX content of XXXXX email that varies, not XXXXX message you show on XXXXX screen.

I wish all websites did this but, unfortunately, it seems to be quite rare, hence my not botherin' to name and shame those websites which don't adhere to this advice (it would take too long).