A common problem when penetration testing web applications is e-mail enumeration.
E-mail enumeration is possible when the application reveals e-mail addresses that have already registered/used the service. With this bit of information it becomes possible to perform brute-force password attacks, or use the harvested information for another purpose. This enumeration process is commonly performed in two places (authentication and password reset) that can easily be secured. However, there are routes often several other vulnerable attack surfaces.
In this post I intend to explain how the two well known routes can be secured, where and what the others are, and how they can all be secured using a proper process.
Authentication
The largest problem with authentication screens is with the messaging.
If an application is vulnerable, it will tend to discriminate between an incorrect password and an incorrect e-mail address. This is simple to solve (and is probably why it does not occur that frequently) by changing the error message to be the same in both cases.
The only downside to changing the messaging in this way is that legitimate users may be led to believe that they have registered even when they haven’t. There are things that can be done though to reduce the risk of this, for example, by providing a link to the registration page in the message.
Password Reset
If the authentication screen is not vulnerable, the next best place to attempt an e-mail enumeration attack is the password reset screen.
Again this screen is most vulnerable to leaking information about an e-mail address through poor messaging and can be secured by using a generic message in cases where an account exists or not. Behind the scenes, these are treated differently and a link to the next step should only be issued if a matching account exists. Unless the attacker has access to the e-mail account too, they will never know if the e-mail was sent or not.
Registration
Alarmingly, whilst authentication and password reset screens are often well protected, registration screens almost never are even though the same opportunities arise (e.g. “an account already exists with this e-mail address”). The reason for this is likely to be because they require a more significant process change.
In many web applications these days, validating the e-mail address at registration is considered an important step because it is the primary marketing channel to the user. There are lots of methods of varying complexity, but perhaps the simplest is to actually send an e-mail requiring some action by the recipient.
Often this activation e-mail is sent after the registration process has been completed. Instead, if this e-mail is sent at the start of the process (and the registration screen kept short at this point), it is possible to eliminate the enumeration loophole.
To do this requires that the registration screen is split into three: capture e-mail address, send invitation e-mail, complete profile. The invitation e-mail can then contain specific instructions for users who are attempting to register with an existing e-mail address, but may have forgotten their password, or are trying to register for the first time. It also means that again, unless the attacker has control of this e-mail account they will not learn anything about it.
Change E-mail Address
This is another forgotten attack surface that should behave similarly to the registration process..
Once the new e-mail address has been collected, an e-mail should be sent to it and no action should be performed against the account. This message will again vary depending on the precense of an existing account with the same e-mail address. If the e-mail address is already taken, the message should explain that the change is not possible. Conversely, if the e-mail address is available the message should contain a link that completes the change against the account.
This too works by ensuring that unless the attacker has control over the enumerated address (in which case they are learning nothing new), they again not be able to see the contents of this message.
Username Enumeration
I will not go into detail in this post about username enumeration because it is a subtley different problem to e-mail enumeration. I will mention though that, even with usernames, it is far easier to remove possible attack surfaces by requiring an e-mail address at authentication etc. than a username (i.e. the username is a pseudonym).
Alternatively, it is possible to use system generated usernames that are issued at registration. Unfortunately though these tend to be meaningless to humans and get forgotten quickly and to work securely many of the above procedures must be followed.
Conclusion
The attack surface for e-mail enumeration is far wider than many people anticipate and it requires properly designed procedures to mitigate it.
For more information and security recomendations I suggest checking out:
Leave a Reply