Enumeration attack dangers

Recently, while testing a blockchain platform for vulnerabilities, our Kaspersky Blockchain Security experts found that the platform’s password recovery process was vulnerable to an attack through user name enumeration. Web developers need to be aware of this kind of attack and its dangers.

What’s an enumeration attack?

Web applications with password and login authentication typically include several components that interact with the user database: the login window (for obvious reasons), the registration form (to avoid duplication of user names), and the password reset page (to make sure that the corresponding account exists). If Web developers do not implement these features securely enough, attackers may be able to use them to determine if a certain username exists in the database.

In the past, it was common for developers to implement all of those features without any protection, and attackers could use a list of usernames and a program that entered them one by one. Over time, to keep potential hackers out, developers began to apply protective tricks such as captcha, limits on the number of login attempts, and the use of asterisks or other means to conceal certain response details.

In modern Web applications, the login window usually has this kind of protection. However, registration forms and password reset pages sometimes lack it. In addition, Web developers do not always consider that the presence or absence of a user in the database can be determined by the timing of the server response. For example, if the user name appears in the database, the server’s response takes 2 milliseconds. If not, the response takes twice as long — 4 milliseconds. To a human being, the difference is undetectable, but for automated enumeration tools, it’s easy to see.

The dangers of a user name enumeration attack

An enumeration attack allows a hacker to check whether a name exists in the database. That will not allow the hacker to log in immediately, but it gives them half of the necessary information. For example, to set up a brute-force attack, rather than searching through login and password pairs, all they need is a matching password for a verified user name, saving time and effort.

Remember as well that almost every service uses e-mail addresses as user names. Therefore, the average user has one login for many websites, and not all sites take security equally seriously; news of login and password combination leaks is depressingly common. Consolidated collections of data from these leaks are available on hacker message boards. Also, people tend to use the same passwords on different websites, so after making sure that a user name exists on your website, an attacker can tap a collection like that to see if passwords for the same user exist on other sites — and then try those passwords.

In addition, spear-phishing operators often employ enumeration attacks during the reconnaissance phase. Having ascertained that their target has an account with your service, they can send an e-mail that appears to come from you, asking the user to change their password and linking to a phishing page that looks like your website. When the unsuspecting customer enters a new password, they also have to confirm the old one — and thus provide the scammers with all they need.

How to protect yourself from an enumeration attack

Have you ever noticed how modern websites respond to the submission of a password reset form? They do not say “A link to reset your password has been sent to you” or “The specified e-mail is not in our database,” as websites used to. Instead, they write, “If this e-mail exists in our database, we will send you a message with a link.” In other words, websites do not explicitly confirm or deny the existence of the user name. They made the change specifically to protect against enumeration attacks.

In the same vein, there is no need for you to explain in detail in the login window that the user entered an incorrect password or that no such user name exists in the system. Just say that the login/password combination was not found. It’s not ideal from a UX standpoint — I, for one, get exasperated when I forget which e-mail I used for registration but I’m pretty sure about the password, or vice versa, but the website gives me no clue about which field I got wrong. However, security virtually always comes at the cost of comfort, and in the case of authentication services, a minor security bias is justified.

Of course, use of a captcha and limitations on login attempts are also a must. In addition to that, to ensure the security of your Web application, we recommend undergoing a third-party audit. And if you are in blockchain technology, our colleagues from Kaspersky Blockchain Security can help with Web application security analysis.