Testing for Weak lock out mechanism (OWASP-AT-004)
This article is part of the new OWASP Testing Guide v4.
At the moment the project is in the REVIEW phase.
Back to the OWASP Testing Guide v4 ToC: https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents Back to the OWASP Testing Guide Project: http://www.owasp.org/index.php/OWASP_Testing_Project
Account lockout mechanisms are used to mitigate against brute force password guessing attacks. Accounts are typically locked out after 3 to 5 unsuccessful login attempts and can only be unlocked after a predetermined period of time, via a self-service unlock mechanism, or intervention by an administrator. Account lockout mechanisms require a balance between protecting accounts from unauthorized access and protecting users from being denied authorized access.
Note that this test should cover all aspects of authentication where lock out mechanisms would be appropriate, e.g. when the user is presented with security questions during forgotten password mechanisms (see Testing for Weak security question/answer (OTG-AUTHN-008)).
Description of the Issue
Without a strong lock out mechanism, the application may be susceptible to brute force attacks. After a successful brute force attack, a malicious user could have access to:
- Confidential information / data;
- Private sections of a web application could disclose confidential documents, users' profile data, financial status, bank details, users' relationships, etc.
- Administration panels;
- These sections are used by webmasters to manage (modify, delete, add) web application content, manage user provisioning, assign different privileges to the users, etc.
- Availability of further attack vectors;
- Private sections of a web application could hide dangerous vulnerabilities and contain advanced functionalities not available to public users.
Evaluate the account lockout mechanism's ability to mitigate brute force password guessing.
Evaluate the reactivation mechanism's resistance to unauthorized account re-activation.
Black Box testing and example
Typically, to test the strength of lockout mechanisms, you will need access to an account that you are willing to lock out.
To evaluate the account lockout mechanism's ability to mitigate brute force password guessing, attempt an invalid login by using the incorrect password a number of times, before using the correct password to verify that the account was locked out. An example test may be as follows:
- Attempt to login with an incorrect password 3 times.
- Successfully login with the correct password, thereby showing that the lockout mechanism doesn't trigger after 3 incorrect authentication attempts.
- Attempt to login with an incorrect password 4 times.
- Successfully login with the correct password, thereby showing that the lockout mechanism doesn't trigger after 4 incorrect authentication attempts.
- Attempt to login with an incorrect password 5 times.
- Attempt to login with the correct password. The application returns "Your account is locked out.", thereby confirming that the account is locked out after 5 incorrect authentication attempts.
- Attempt to login with the correct password 5 minutes later. The application returns "Your account is locked out.", thereby showing that the lockout mechanism does not automatically unlock after 5 minutes.
- Attempt to login with the correct password 10 minutes later. The application returns "Your account is locked out.", thereby showing that the lockout mechanism does not automatically unlock after 10 minutes.
- Successfully login with the correct password 15 minutes later, thereby showing that the lockout mechanism automatically unlocks after a 10 to 15 minute period.
A CAPTCHA may hinder brute force attacks, but they can come with their own set of weaknesses (see Testing for CAPTCHA), and should not replace a lockout mechanism.
To evaluate the reactivation mechanism's resistance to unauthorized account reactivation, initiate the reactivation mechanism and look for weaknesses. Typical reactivation mechanisms may involve secret questions/answers, or an emailed reactivation link. The reactivation link should be a unique one-time link, to stop an attacker from guessing or replaying the link and performing brute force attacks in batches. Secret questions and answers should be strong (see Testing for Weak Security Question/Answer).
Note that a reactivation mechanism is simply for unlocking accounts. It is not the same as a password recovery mechanism.
Factors to consider when implementing an account lockout mechanism:
- What is the risk of brute force password guessing against the application?
- Is a CAPTCHA sufficient to mitigate this risk?
- Number of unsuccessful login attempts before lockout. Too few, and valid users may trigger the lockout too often. Too few, and the more attempts an attacker can make to brute force the account. Depending on the application function, a range of 5 to 10 unsuccessful attempts is typical.
- How will accounts be unlocked?
- Manually by an administrator. This is the most secure lockout method, but may cause inconvenience to users and take up the administrator's "valuable" time.
- After a period of time. What is the lockout period? Is this sufficient for the application being protected? e.g. a 5 minute lockout period may be a good compromise between mitigating brute force attacks and inconveniencing valid users.
- Via a self-service mechanism. Is this mechanism secure?
Gray Box testing and example
See the OWASP article on Brute Force Attacks.
Apply account reactivation mechanisms depending on the risk level. In order from lowest to highest assurance:
- Time-based lockout and reactivation
- Self-service reactivation (sends reactivation email to registered email address)
- Manual administrator reactivation
- Manual administrator reactivation with positive user identification