To Be (Enumerated) Or Not To Be

Are user enumeration vulnerabilities a real security concern? User enumeration is when an application reveals whether a user exists to other users.

I used to quote a post from Average Security Guy, here, which I thought was a clear, succinct sentence that explains the issue well.

As an attacker if I can use your login or forgotten password page to narrow my list from 10000 targets to 1000 targets, I will.

Sadly, this blog is no longer there.

Edit: It just moved.

Here are a couple of examples. This site has a user enumeration flaw on the sign-up page:

when the account does not exist vs

when it does.

And this site has a user enumeration flaw on the forgotten password page:

when the account does not exist vs

when it does.

They both reveal whether a username matches the one entered by a potential attacker. As well as a privacy leak, which can have its own consequences, this allows an attacker to automate the process and find out whether it is worth attempting a password guessing attack against the application using their username list. Note these are more of a concern if email address is also used as the username, which in spite of this I would still recommend as otherwise sites end up being overly complicated as you will need forgotten username functionality as well as forgotten password functionality which leads to a cumbersome UI and more complexity, which in turn leads to less security as implementation flaws are no doubt introduced.

The thing is that many bug bounty programmes do not reward user enumeration, and many websites do allow user enumeration to happen. Some websites allow user enumeration by design. For example, Gmail or other Google services. This is because the username of Gmail is considered public anyway. If you have foo@gmail.com you will need to give out foo@gmail.com to people or organisations in order for them to contact you.

Other times, a system is so global that it is presumed that almost everyone will have an account anyway, and there is nothing much to be gained from narrowing down a list. However, for most websites, I’d argue that user enumeration flaws should be eliminated.

Now, contrary to popular belief, this can be eliminated from a user registration process. Sometime ago I wrote this answer here:

This can be solved by implementing an out of band message.

To solve this issue I would have a form which can be used for two purposes:

1. Account recovery.
2. New user sign up.

The single field on this form is Email address. Of course you can use different text depending on whether the user wanted to recover their account or sign up, but the way it works will be the same.

Once the user has entered their email address and clicked Next, the same response will be shown for any address entered. Something similar to Thank you, please check your email account for the provided address.

The “out of band” message sent their email address will either say Please follow the link to recover your account or Please follow the link to sign up to our service and will contain the appropriate links which will include a time-limited token to allow the user to recover their account or sign up as necessary. The only thing that determines the text of this message is whether an account exists for their email address within the system, it does not matter if the user followed the account recovery or new user sign up links.

Now although secure^*, the question is does this ruin the user experience for people just wanting to sign up and potentially buy something at the same time. Lost sale?

Going from the above, the process for an e-commerce site would be:

1. Arrive on site after Googling thing of interest.
2. Find product on merchant site and add to basket.
3. Proceed to checkout.
4. Sign up - email address is entered and submitted.
5. Go to email client and await confirmation email.
6. Click link which will open in new tab and then continue to sign-up and purchase.

Would steps 4 and 5 potentially cause lost sales? It could in the following scenarios:

• User does not have access to their email at their current location (might be using a friend’s PC).
• User’s email is down.
• User enters the wrong email address.
• Email gets filtered into spam.
• User might have access to email on their phone, but are trying to order on a desktop.

So yes, in these circumstances it may lead to a lost sale if the user cannot access the email to complete their sign up. Is there a solution?

Yes. I would say the solution would be to change the process from steps 4 onwards:

1. Same: Arrive on site after Googling thing of interest.
2. Same: Find product on merchant site and add to basket.
3. Same: Proceed to checkout.
4. User enters their contact and delivery address, phone, email and card details (of course with HTTPS with HSTS, but that’s besides my point).
5. Sale made! Note that the email entered is only used to confirm their order, it is not used to register the user.
6. User is prompted whether they wish to register. Answering No ends this process.
7. Sign up - email address is shown, editing is allowed and then can then be submitted. Editing the email will update it on the order.
8. Go to email client and await confirmation email.
9. Click link which will open in new tab and then will register the user or associate the order with their account if the user did not realise they had registered previously.

“The order you won earlier - that’s safe.”

Of course (again) if the user already was signed in then everything would be be pre-filled already without the option to register at the end.

I’d like to know your thoughts on this approach. I like it over the CAPTCHA because it protects user privacy too against a single username query. It doesn’t hamper the purchasing process, but completely protects users against their username being discovered, and completely protects your site against enumeration attacks.

^* of course on very high-security systems you won’t want a password reset via email to be a thing anyway.