Unless an application contains account lockout functionality, an attacker can attempt to log in by brute-force guessing common usernames and passwords. This typically involves brute-force guessing to find a list of valid usernames and then attempting to brute-force passwords.
Solution
The goal is to test whether an attacker can obtain some valid usernames in the application and whether he can continually guess passwords until he gets one right. Attempt the following to determine whether the application intentionally or unintentionally reveals usernames:
Attempt to log in with a username that does not exist. Then, attempt to log in with a username that does exist, but enter an incorrect password. If the application's response in the two cases is different, then the attacker can enumerate usernames in the system.
If the application implements password reset functionality for users that forget their passwords, determine how the password reset functionality works. Does it require the user to enter a username? If so, determine whether the application responds differently depending on whether a valid or invalid username is entered.
Some applications contain functionality to allow users to sign up for accounts themselves. Since usernames need to be unique, the application will indicate to the end user whether the username that she is trying to sign up for already exists. This functionality could be exploited by an attacker to enumerate usernames. Determine whether the application contains such functionality.
If in any of these tests the application allows the attacker to determine valid usernames, the application fails this part of the test. This may or may not be of interest in your particular application. However, if the next test fails, then the failure will definitely be of interest.
The next step is determining whether the application allows brute-forcing passwords. Even if the attacker cannot conclusively get a valid list of usernames, he could still attempt to brute-force passwords for common usernames that may or may not be valid in the application (e.g., jsmith). Attempt one of the following depending on your circumstances:
If there is a requirement concerning account lockout functionality, test it by entering an incorrect password for a valid username several times (as dictated by the requirement) and determine whether the account is locked out by entering the same username with the corresponding valid password. Also, if the account is locked out, determine whether the application provides the same response regardless of whether the entered password is correct. If after account lockout it provides different responses depending on whether the password is correct or not, the attacker can still brute-force the password. However, he will not be able to actually log in until the account is unlocked.
If there is no requirement concerning account lockout functionality, determine whether account lockouts are enforced by entering an incorrect password for a valid user account a number of times (10 to 15 times should be sufficient). Then, enter the valid password and see if the account is locked out. As in the previous test, even if the account is locked out, determine whether the application's response is different depending on whether the entered password is correct or not.
The application fails this test if it either does not enforce account lockout functionality, or locks out accounts and then provides different responses depending on whether the entered password is correct or not.
Discussion
Usernames and passwords are frequently brute-forceable even in the presence of account lockout functionality or other mitigating measures. Applications often try to be helpful and provide different error messages to users depending on whether the supplied username is incorrect or the supplied password is incorrect. This is often true even after an account gets locked out. The authors have seen an application that displayed error messages similar to the following. If the username was incorrect, the application stated that "The username or password is incorrect"; if the password was incorrect, the user would get the message "The user could not be authenticated"; if the account was locked out and the password was correct, the user would get a message stating "Your account has been locked out." This provides an easy way to brute-force usernames and passwords.
In the earlier example, an attacker could enumerate usernames by entering different values and recording whether the application stated that "The username or password is incorrect" or "The user could not be authenticated." The attacker could then brute-force the password by waiting to either get logged in or get the message "Your account has been locked out." Even if the attacker locks out an account while brute-forcing, he will just need to wait until the account is unlocked before accessing it. Many applications unlock accounts automatically after a predetermined amount of time.Note that it is typically easy for attackers to guess at least a small number of usernames and passwords in most systems. This is because usernames tend to be predictable, and many users tend to choose very weak passwords
Vinay Jagtap
A hard core Technocrat with over a decade of extensive experience in heading complex test projects coupled with real time experience of project management and thought leadership. Extensive experience in Performance, Security and Automation Testing and development of automation frameworks and ability to setup and execute Global service centers and Center of Excellences for testing.
Get Free Email Updates to your Inbox!
