Preventing Username Enumeration Attacks with Spring Security

1. Overview

In this tutorial, we’ll describe enumeration attacks in general. More specifically, we’ll explore username enumeration attacks against a web application. And, most importantly, we’ll explore options for handling them through Spring Security.

2. Explaining Enumeration Attacks

Enumeration technically means complete and ordered listing of all the items in a collection. Although this definition is restricted to mathematics, its essence makes it a potent hacking tool. Enumeration often exposes attack vectors that can be employed for exploitation. In this context, it is often known as resource enumeration.

Resource enumeration, as the name suggests, is a way to gather a list of resources from any host. These resources can be anything of value, including usernames, services, or pages. These resources can expose potential vulnerabilities in the host.

Now, there can be several possible ways, explored or even unexplored, to exploit these vulnerabilities.

3. Popular Enumeration Attacks for Web Applications

In a web application, one of the most often employed enumeration attacks is username enumeration attack. This basically employs any explicit or implicit feature of the web application to gather valid usernames. An attacker may use popular choices of username to attack the web application.

Now, what kind of feature in a web application may reveal whether a username is valid or not? Honestly, it can be as varied as possible. It may be a feature as designed, for example, a registration page letting a user know that the username is already taken.

Or, this may be as implicit as the fact that a login attempt with a valid username takes a much different amount of time compared to one with an invalid username.

4. Setup to Emulate Username Enumeration Attack

We’ll use a simple user web application using Spring Boot and Spring Security to demonstrate these attack vectors. This web application will have a minimal set of features to support the demonstration. A detailed discussion on how to set up such an application is covered in a previous tutorial.

Common features on a web application often reveal information that can be used to launch enumeration attacks. Let’s go through them.

4.1. User Registration

User registration needs a unique username, and email address is often chosen for simplicity. Now, if we pick an email which already exists, the application ought to tell us so:

Coupled with the fact that a list of emails is not hard to come by, this can lead to a username enumeration attack to fish out valid usernames in the application.

4.2. User Login

Similarly, when we try to login into an application, it requires us to provide username and password. Now, if a username we provide does not exist, the application may return this information to us:

This, as before, is simple enough to harness for a username enumeration attack.

4.3. Reset Password

Reset password is often implemented to send a password reset link to a user’s email. Now, again this will require that we provide a username or email:

If this username or email does not exist in the application, the application will inform as such, leading to a similar vulnerability as we saw earlier.

5. Preventing Username Enumeration Attacks

There can be several ways to prevent a username enumeration attack. Many of them we can achieve through simple tweaks in the features like user messages on a web application.

Moreover, Spring Security over time has matured enough to support handling many of these attack vectors. There are features out-of-the-box and extension points to create custom safeguards. We’ll explore some of these techniques.

Let’s go through popular options available to prevent such attacks. Please note that not all of these solutions are suitable or even possible in every part of the web application. We’ll discuss this in more detail as we go along.

5.1. Tweaking Messages

First, we must rule out all possibilities of inadvertently giving out more information than what is required. This would be difficult in registration but fairly simple in login and reset password pages.

For instance, we can easily make the message for login page abstract:

We can do similar tweaks to the message for the password reset page.

5.2. Including CAPTCHA

While tweaking the messages works well on some pages, there are pages like registration where it’s tricky to do so. In such cases, we can use another tool called CAPTCHA.

Now, at this point, it’s worthwhile to note that any enumeration attack most likely is robotic due to a vast number of possibilities to go through. Hence, detecting a human or robotic presence can help us prevent an attack. CAPTCHA serves as a popular way to achieve this.

There are several possible ways to implement or integrate CAPTCHA services in a web application. One of these services is reCAPTCHA by Google, which can be easily integrated on the registration page.

5.3. Rate Limiting

While CAPTCHA serves the purpose well, it does add latency and, more importantly, inconveniences to legitimate users. This is more relevant for frequently used pages like login.

One technique that can help prevent robotic attacks on frequently used pages like login is rate limiting. Rate limiting refers to preventing successive attempts for a resource after a certain threshold.

For example, we can block requests from a particular IP for a day after three failed attempts at login:

Spring Security makes this particularly convenient.

We begin by defining the listener for AuthenticationFailureBadCredentialsEvent which will count the number of failed attempts by source IP. When an attacker tries to run a brute force attack it will block after the threshold that was set in the LoginAttemptService and it will not be able to reset the counter for 24h. Once a set threshold is breached, subsequent requests are blocked in the UserDetailsService. We also check at every failure if the user is blocked and generate the correct error message.

A detailed discussion on this approach is available in another tutorial.

5.4. Geo Limiting

Additionally, we can capture the location by country of a user during registration. We can use this to verify a login attempt originating from a different location. If we detect an unusual location, suitable action can be taken:

• Enable Captcha selectively
• Enforce step-up authentication (as part of multi-factor authentication)
• Ask the user to verify the location securely
• Block the user temporarily on successive requests

Again, Spring Security, through its extension points, makes it possible to plug in a custom location verification service in the AuthenticationProvider. A particular flavor of this has been described in detail in a previous tutorial.

5.5. Multi-Factor Authentication

Lastly, we should note that password-based authentication is often the first and, in most cases, the only step required. But it’s not uncommon for applications to adopt multi-factor authentication mechanisms for better security. This is especially true for sensitive applications like online banking.

There are many possible factors when it comes to multi-factor authentication:

• Knowledge Factor: This refers to what a user knows, like PIN
• Possession Factor: This refers to what a user possesses, like a token or smartphone
• Inherence Factor: This refers to what a user inherently has, like fingerprints

Spring Security is quite a convenience here as well, as it allows us to plug in a custom AuthenticationProvider. The Google Authenticator app is a popular choice to implement additional possession factor. This allows users to generate an ephemeral token on the app in their smartphone and use it for authentication in any application. Obviously, this requires setting up the user beforehand in the application, either during registration or later on.

Integrating Google Authenticator in a Spring security application has been well covered in a previous tutorial.

More importantly, a solution like multi-factor authentication is only suitable if the application needs it. Hence, we should not use it primarily to prevent enumeration attacks.

5.6. Processing Time Delays

While processing a request like a login, checking if the username exists is often the very first thing we do. If a username does not exist, the request immediately returns with an error. On the contrary, a request with a valid username would involve many further steps, like password match and role verification. Naturally, the time to respond to both these cases may vary.

Now, even though we abstract the error message to hide the fact of whether a username is valid or not, a significant difference in processing time may tip off an attacker.

A possible solution for this issue can be to add a forced delay to rule out the difference in processing times. However, as this is not a problem that can occur with certainty, we should only employ this solution if necessary.

6. Wrapping Up

While we covered a lot of tricks to use when it comes to username enumeration attacks, it’s natural to ask, when to use what? Obviously, there’s no one answer for this, as it’s largely based on the type of application and its requirements.

A few things, like messages to the user, must leak as little information as possible. Additionally, it’s wise to restrict successive failed attempts towards a resource like login.

However, we should use any additional measures only if requirements deem them necessary. We should also weigh them rationally against the deterrence to usability.

Moreover, it’s important to realize that we can apply any combination of these measures for different resources to selectively secure them.

7. Conclusion

In this tutorial, we discussed enumeration attacks – username enumeration attacks, in particular. We saw that through the lens of a simple Spring Boot application with Spring Security.

We went over several ways to progressively address the concerns of username enumeration attacks.

Lastly, we discussed the appropriateness of these measures in application security.