Username enumeration is primarily used to provide greater efficiency to a password- guessing attack. This approach avoids wasting time on failed attempts using passwords for a user who doesn’t exist. For example, if you can determine there is no user named Alice, there’s no point in wasting time trying to guess Alice’s password. The following are some examples of functionality often used in web applications that may allow you to determine the username.
Profiling Results In Chapter 2, we discussed a few places to identify ambient user information within a web site, such as source code comments. Smart attackers always review their profiling data because it’s often a rich source of such information (textual searches across the profiled information for strings like userid, username, user, usr, name, id, and uid often turn it up).
In Chapter 8, we will also discuss common web site structures that give away usernames—the most obvious offender here is the directory named after a user that service providers commonly employ to host customer web content (e.g., http://www .site.com/~joel).
Error Messages in Login A simple technique to determine if a username exists is to try to authenticate to a web application using invalid credentials and then examine the resulting error message. For example, try authenticating to the target web application using the usernameAlice and the password abc123. You are likely to encounter one of three error messages similar to the ones listed here, unless you actually successfully guessed the password:
• You have entered a bad username. • You have entered a bad password.
• You have entered a bad username/password combination.
If you receive the first error message, the user does not exist on the application and you should not waste any time trying to guess the password for Alice. However, if you received the second error message, you have identified a valid user on the system, and you can proceed to try to guess the password. Lastly, if you received the third message, it will be difficult to determine if Alice is actually a valid username (this should be a hint to application designers to use the third message in their own authentication mechanisms).
A good example of this is the login functionality implemented by the SiteMinder web authentication product from Computer Associates (CA), who acquired the technology with its acquisition of Netegrity in November 2004. With SiteMinder, you can perform username enumeration by evaluating the error page. If an incorrect username is entered, the site attempts to load nouser.html. If a valid username is entered with an incorrect password, the site attempts to load failedlogin.html.
Error Messages in Self-Service Password Reset Features Similar to the user enumeration vulnerabilities just discussed, self-service password reset (SSPR) functionality is also a common source of user enumeration disclosure vulnerabilities. SSPR is a feature implemented by many web sites that allows users who have either forgotten their password or are otherwise unable to authenticate to fix the problem themselves via “self- service”; the most typical implementation is a “Forgot Password?” or similar link that e-mails a new password to the e-mail address specified by the user. The e-mail address “authenticates” the user via an alternate mechanism, assuming only the user in question can access that e-mail account and retrieve the new password.
Unfortunately, applications that insecurely implement this functionality will often report whether the supplied user account name or e-mail address is valid. An attacker can use the difference in the response between the valid and invalid case to detect whether the account exists.
In addition to user enumeration, applications that randomly generate new passwords in response to SSPR requests are also vulnerable to denial-of-service (DoS) attacks. For example, a particularly malicious attacker might create a script to request new passwords repeatedly for each username that is discovered. If the requests are repeated frequently enough, this will flood the target user accounts with e-mails containing new passwords, never allowing that user enough time to use the new password to authenticate against the application.
Registration Many web applications allow users to select their own usernames in the registration process. This presents another vector for determining the username. During the registration process, if you select a username of another user who already exists, you are likely to be presented with an error such as “Please choose another username.” As long as the username you have chosen follows the application guidelines and does not contain any invalid characters, this error message is likely an indication that the chosen username is already registered. When given a choice, people often create usernames based on their real names. For example, Joel Scambray may choose usernames such as Joel, JoelS, JScambray, etc. Therefore, attackers can quickly generate a list of common usernames based on real names found in phone books, census data, and other online resources. CAPTCHA technology can be deployed to help mitigate the risk of these attacks. Detailed information on CAPTCHA is available in the “User Registration Attacks” section of this chapter.
Account Lockout To mitigate the risk of a password-guessing attack, many applications lock out accounts after a certain number of failed login attempts. Depending on the risks inherent to the application, account lockout thresholds may be set to 3, 5, or more than 10 failed authentications. Many high-volume commercial web sites set the lockout threshold much higher (e.g., 100 failed attempts) to defray the support costs related to unlocking user accounts (typically higher for lower lockout thresholds); again, there is a balance between ease-of-use/support and security that varies depending upon the specific risks faced by a given application. Applications also commonly unlock accounts automatically after a period of 30 minutes, 1 hour, or 24 hours. This is also done to reduce the number of calls made to the support desk to reset accounts. This countermeasure
effectively slows down a password-guessing attack and, given a good password policy, is considered a good balance of security and usability.
However, account lockout only makes sense for valid usernames. How do you lock out an account that doesn’t exist? These are subtleties that many applications implement incorrectly. For example, if the account lockout is set at 3, will an account be locked out if it doesn’t exist? If not, you may have stumbled upon a way to determine invalid accounts. If you lock out an account, the next time you log in, you should receive an error message. However, most applications don’t track this for invalid accounts. Lastly, the best way to prevent username enumeration from account lockout is to not tell the user he or she was locked out at all. This, however, will almost surely result in a frustrated and angry user.
Sometimes account lockout is implemented using client-side functionality like JavaScript or hidden tags. For example, there may be a variable or field that represents login attempts. It is trivial to bypass client-side account lockout by modifying the client- side JavaScript or by using a proxy to directly POST login actions (the Burp Suite repeater functionality is good for this; Burp Suite is discussed in Chapter 2) and bypass the JavaScript altogether.
Timing Attacks If all else fails, a timing attack may be the last resort of a frustrated attacker. If you can’t enumerate usernames from error messages, registration, or password changes, try calculating the time it takes for an error message to appear for a bad password versus a bad username. Depending on how the authentication algorithm is implemented and the types of technologies used, there may be a significant difference in the time it takes for each type of response (“bad username” versus “bad password”). Observing differences in response timing can provide clues to legitimate usernames and passwords. However, for this technique to be effective, the difference needs to be large enough to overshadow fluctuations due to network latency and load. Keep in mind that this technique is prone to producing a large number of false positives.
Before moving into the next section on password guessing with known usernames, we should note that allowing attackers to determine the username is a risk that many online businesses have simply accepted, despite the protestation of concerned security professionals.