← Older revision
Revision as of 02:12, 3 December 2013
(One intermediate revision by one user not shown)
Line 4:
Line 4:
== Summary ==
== Summary ==
−
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
unauthorised
access and protecting users from being denied
authorised
access.
Factors to consider
when
implementing an account lockout mechanism:
+
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.
<br>
+
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)]]).
−
# What is the risk of brute force password guessing against the application?
+
== Description
of the
Issue ==
−
# Is a CAPTCHA sufficient to mitigate this risk?
+
−
# Number of unsuccessful logon attempts before lockout
+
−
# How will accounts be unlocked?
+
−
## Manually by an administrator
+
−
## After a period
of
time. What is
the
lockout period?
+
−
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)]]
).
+
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
.
== Test objectives ==
== Test objectives ==
Line 19:
Line 24:
Evaluate the account lockout mechanism's ability to mitigate brute force password guessing.
Evaluate the account lockout mechanism's ability to mitigate brute force password guessing.
−
Evaluate the
re-activation
mechanism's resistance to
unauthorised
account re-activation.
+
Evaluate the
reactivation
mechanism's resistance to
unauthorized
account re-activation.
−
==
How to test
==
+
==
Black Box testing and example
==
−
# Number
of
unsuccessful logon attempts
before lockout
+
Typically, to test the strength
of
lockout mechanisms, you will need access to an account that you are willing to lock out.<br>
−
#
How will accounts be unlocked?
+
<br>
−
##
Manually by
an
administrator
+
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:
−
##
After a period of time
.
What
is the lockout period
?
+
# 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
.
+
<br>
+
A CAPTCHA may hinder brute force attacks, but they can come with their own set of weaknesses (see [[Testing_for_Captcha_(OWASP-AT-012)|Testing for CAPTCHA]]), and should not replace a lockout mechanism.
−
=== Example ===
+
<br>
+
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_(OTG-AUTHN-008)|Testing for Weak Security Question/Answer]]).<br>
+
Note that a reactivation mechanism is simply for unlocking accounts. It is not the same as a password recovery mechanism.<br>
+
<br>
+
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 ==
Line 36:
Line 64:
== References ==
== References ==
+
See the OWASP article on [[Brute_force_attack|Brute Force]] Attacks.
== Remediation ==
== Remediation ==
−
−
Implement CAPTCHA with the account logon page.
Apply account reactivation mechanisms depending on the risk level. In order from lowest to highest assurance:
Apply account reactivation mechanisms depending on the risk level. In order from lowest to highest assurance: