One key part of an attack is for the threat actor to identify valid users for the aspect they are targeting. Once a set of valid users is obtained these can be further targeted in an attempt to access their accounts.
Equally, there may also be privacy concerns that users of your website, for example, might not want this disclosed. In addition, during Red Team engagements this is an easy low-risk way to identify information for wider attacks. This SureCloud blog demonstrates some of the most common forms of username enumeration whilst also explaining the risks associated with this vulnerability.
Enumeration through application response
While performing application tests we often find ways in which it is possible to enumerate usernames. Most websites we test protect the login form but as an example let’s consider the following login form.
When an attacker attempts to perform username enumeration on this page they will attempt to see if the response to the application differs between a valid username and an unused username.
In the example, above it’s clear that Pete is a valid username and Bob is not. A better response would be to always return the same error message for both cases.
This example does not suffer from an obvious enumeration vulnerability, but just ensuring the final output is the same is not sufficient to protect against enumeration. Another class of enumeration is timing enumeration.
Enumeration through timing analysis
Timing enumeration exploits the fact that applications may take differing amounts of time to respond depending on if the username is valid or not. Take the login form example from the first section of this post, this could be implemented as two steps. First, the username is looked up to see if it’s valid, and only if it’s valid is the slow hashing of the password performed.
By timing how long the request to the return from the server it would be possible to determine if a username is valid. If the difference is small the average of a large number of requests may be needed to see spot the difference.
Email addresses as usernames
We find a large number of sites that use email addresses as usernames, while this is not an issue in itself care must be made throughout the application to ensure that the email addresses are not vulnerable to enumeration vulnerabilities. It should also be noted that the enumeration of email addresses itself may be sensitive information. A user’s email address is often public knowledge if you can perform email address enumeration on a site, such a dating site and correlate this to a real person this information could be used to for social attacks such as blackmail.
Enumeration through password reset
While sites may protect the login form, if they are using email addresses as usernames they need to ensure that enumeration is not possible through the password reset form. Take the two examples bellow, in one an error message is returned when an email address is not recognized. The other is an example of a potential response that could be used that would not allow for username enumeration.
Enumeration through change password workflow
Users often lose access to email addresses, and as such a workflow where users can change their registered email address is important. As above though if this email address is used for username it’s important that these cannot be enumerated. Below is an example of a badly implemented email address form that allows for enumeration.
A better workflow that does not allow for email address enumeration would be inform the user to check their emails to confirm email.
APIs
Don’t forget your APIs! Your front end might not reveal if a username/email address is in use or not, but if you are calling an API from the browser ensure that these also do not allow for enumeration. For example, a login form that calls an API might show the same output to the user for either an incorrect username and password if the responses to the API are different an attacker will be able to see this differences by inspecting the API responses.