Auth & identity
August 30, 2023
Author: Stytch Team
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.
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.
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.
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.
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.
Limit how much user state you share with your frontend (user-facing client).
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
Whether on their own or in addition to MFA, you can also consider primary auth methods that are inherently safer from enumeration tactics:
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.
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:
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.