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.
