A Different Kind of DoS Attack

I locked my wife out of her webmail account the other day, unintentionally.  I won't go into boring the details of why I was trying to get into her email, but as a disclaimer let me say that we both have access to each other's webmail account, out of trust.  But in this instance I couldn't get a hold of her and I just needed a snippet of info.  It was late, I was tired and impatient, so I just kept on trying password after password.  Eventually I just gave up and went to bed.

A few hours later I was awoken  by my wife yelling "you locked me out of my email account!"  She might have called me something too.

Due to the her webmail provider's security policy, even after she had entered alternative personal information to reset her password, her account was locked for 24 hours.  So I had ostensibly executed a Denial of Service (DoS) attack on exactly the wrong person:  my wife.

A common organizational security policy is to lock a user's account after three failed login attempts; in order to unlock it, the user must then contact the help desk.  This policy therefore constitutes a DoS vulnerability, because anyone can lock a user's account if the victim's login ID is known:  just enter anything for the password three times and the user gets locked out (or denied service.)  This common policy is drafted assuming failed login attempts are done either by a well-intentioned user who fat-fingered or forgot the password, or by an attacker who is trying to guess the password in order to gain access to the system. But there is this other possibility: an attacker intentionally botching a user's login in order to lock the victim out.   

This form of a DoS attack should at least be considered when drafting a login failure policy.  Otherwise, workstations and webmail accounts alike will remain vulnerable to this unusual form of a DoS attack.

Comments

[Sebastián]

Nice story! Another view point.

[Sean M. Price]

Categorizing a security control, such as lockout due to excessive invalid attempts, as a DoS or a form of vulnerability is problematic. At what point is a security control too restrictive? What is the value of the asset protected? What is the impact to the business due to the activation of the control? These questions are relevant to the selection of a security control. Although the effect described is a DoS it is not advisable to consider a security control from this perspective. Similarly, a properly functioning security control supporting an established security policy should also not be considered a vulnerability. Rather, policy and procedure development should focus on ways to quickly reestablish availability for the user as well as counteract active attacks. A high degree of confidence regarding subsequent authentication is essential to maintain the established security services of the system. The problem you describe is an effect of using single factor authentication. The control is necessary due to the high probability that a user will create a weak password. However, if two factor authentication was used with a high degree of assurance that it could not be easily circumvented then a lockout enforcement mechanism might not be necessary. If a brute force attack requires a substantially large search space (i.e. 2X10^128) then the risk of correctly guessing the correct key is quite small. Additionally, security monitoring through audit logs could also be used to detect and respond to brute force attacks. Misbehaving traffic could be blocked or dropped to reduce the ability to continue the attack. In this regard defense in depth is an important consideration when developing policy, procedures, and security controls addressing the threat and attack pairing.