In a previous article we went over enumeration attacks – what they are, how they work, and what’s at risk.
In this article, we’ll look at how you can protect your web application against these kinds of attacks.
Remind me: what’s an enumeration attack?
Account or user enumeration attacks occur when a bad actor tries to identify valid users, emails, etc within web applications’ authentication flows.
Enumeration attacks are primarily used to gain information about a system that can be used in further attacks, and does not directly result in compromised accounts. Because it’s most successful when executed at scale, it’s typically performed and classified as a brute force attack.
To learn, read our blog on the ins and outs of enumeration attacks.
Best methods for preventing enumeration attacks
Generally, non-sensitive consumer applications carry very little risk from user enumeration attacks. In fact, user enumeration via useful and actionable error messages is often helpful for consumer login flows. For example, telling a user that their login failed because they do not have an account is a better user experience than presenting a generic failure message.
However if your domain is particularly sensitive to security, e.g. government, fintech, healthcare etc, or your application is at a large enough scale, we do recommend you take a few steps to protect your against account enumeration.
Compose your error messages carefully on your login and password reset page
Don’t use error messages that give away key information about why a particular action failed. This applies for both login forms and password reset pages.
For example, if an actor initiates a password reset for an account that does not exist, don’t show an error message. Instead, show a message to the effect of “If an account is associated with that email, a reset link has been sent.”
Again, it’s worth noting that if your message is too vague, it may frustrate users, so it’s up to you to find the right balance between a message that will aid legitimate users and thwart those of ill-intent.
Conceal PII
Don’t expose unmasked Personally Identifiable Information (PII), e.g. only display the last four digits of a phone number in your UI as opposed to the full value.
Show discretion with your user state
Limit how much user state you share with your frontend (user-facing client).
Incorporate multi-factor authentication into your login flow
While the initial impact of an enumeration attack may be limited, the end goal is of course account takeover. One of the surest ways to prevent account takeover is multi-factor authentication.
This means that even if a hacker gains access to a valid username and its matching password, they won’t be able to log in without additional access to other accounts or devices belonging to that user, such as their phone, tablet, or email. The most common types of multi-factor authentication are:
- SMS or email-based one-time passcodes (OTP): SMS OTP asks users to enter a unique numeric or alphanumeric sequence (e.g. 123456) sent by text to a recognized mobile phone number or email.
- Time-based one-time passwords (TOTPs): Also known as authenticator apps, TOTP asks users to confirm control of their device within a certain time frame via a passcode generated by a smartphone app like Google Authenticator, Authy, Duo, or others.
- Push notification via their app: In this option, the app itself sends a notification to a registered and authenticated device belonging to the user, which the user must approve before logging in. Some of the most common of these are Google and Apple push notifications.
- Hardware authenticators (e.g. YubiKey): Cross-platform hardware authenticators like YubiKeys enable users to use a hardware device external to their phone or laptop to verify possession of this factor.
Consider auth methods more immune to enumeration
Whether on their own or in addition to MFA, you can also consider primary auth methods that are inherently safer from enumeration tactics:
- OAuth: Sometimes referred to as “social logins,” OAuth allows users to log into an application using a 3rd party identity provider without sharing or exposing information about a user’s credentials.
- In-device biometrics: Built-in device biometrics allow users to verify themselves with the same facial recognition or fingerprint identification they use to access their phone or laptop. No biometric data is ever passed to the application, but the user is able to verify possession of both the user’s device and a biometric marker.
- Passkeys: While passkeys were recently launched with the goal to replace, not supplement, usernames and passwords, they are a powerful new login method that elides the pitfalls of usernames and passwords by leveraging cryptography and biometric information together. This makes them a great anecdote for enumeration attacks. Learn more about how passkeys work on our blog.
Randomize server response times
As we mentioned in our last article [insert link] an enumeration attack need not even read an invalid user username message to deduce whether or not a username exists. Instead, hackers can simply monitor server response times, as the response time for an invalid username is usually much higher than for a valid one.
An easy way to thwart this type of enumeration attack is by randomizing server’s response times, so that there’s no correlation between them and valid or invalid username entries.
Reduce login attempts with rate-limiting, CAPTCHA, or device fingerprinting
Enumeration attacks are only feasible for most hackers if they are able to execute vast amounts of login attempts. As we mentioned in our last article, even failed login attempts help them deduce information about a user database.
There are three main ways to limit login attempts to web applications:
- Rate limiting: Rate limiting limits the amount of times a user can take a specific action within a designated time frame.
- CAPTCHA: CAPTCHA tests give the user agent tasks that only a human being should be able to complete. By design, they should help stop automated enumeration attacks then by identifying and stopping bots in their tracks – but they still have a few loopholes.
- Device Fingerprinting: Device fingerprinting identifies the devices that access a website or application by tracking a given set of device attributes, IP address, browser brand and version, operating systems (OS), and more.
Got more questions? Stytch can help.
At Stytch, we pride ourselves on being an identity platform that’s powerful enough to meet your toughest security requirements, while adaptable enough to fit any app’s stack, use case, and scale.
From multi-factor authentication to fraud and risk tools like sophisticated device fingerprinting and Strong CAPTCHA, our identity platform has everything you need to secure and scale your app.
Share
