To lock or not to lock, that is the question

Many websites believe they have the problem of password guessing solved.  They do what is called “account locking”: if the customer enters an incorrect password X number of times – sequentially – the website locks them out.  The lockout can be for a specified amount of time or until they contact customer support to get their account unlocked.

I don’t have quantitative data on the number or percent of websites that use this approach, but I am encouraged to see that researchers and others are beginning to understand the deficiencies of using this as a security mechanism.  There are two main reasons why account locking doesn’t help with password guessing: negative customer experience and horizontal password guessing attacks.

The customer experience of account locking is important to consider.  Because security experts have encouraged people to have different passwords for all of their online accounts, consumers now must remember dozens of passwords.  When logging in to a particular website, it would not be uncommon for the average person to have to try several different passwords before they remember the one that is correct for that site.  In the case of account locking, it is likely that the consumer will get locked out of their account when they are trying their various passwords and this results in a negative customer experience.

The responses consumers have to getting locked out can vary.  On one extreme, the customer waits until the lockout period has ended (sometimes you know how long you are locked out, but a lot of times you don’t).  In the middle of the extremes, the customer either calls customer support or, in the case of a bank, goes to a brick and mortar branch of the bank to perform their transaction.  On the far end of the extreme, the customer decides to take their business somewhere else.

Although I have not seen hard data on the cost of account locking to websites and especially financial institutions, I’m guessing that the cost of the customer support calls, branch visits, and customer attrition are not negligible.

One bank tried a unique approach to avoid using password lockout. This was a bank implemented a CAPTCHA (the fuzzy numbers in the box you must type in to prove you are human and not a computer) for every login. They implemented the feature without any user testing thinking this would eliminate password guessing. They ended up with so much negative push back from their customers, they had to take the feature off. This was a clear case where the true cost of the solution (extreme negative customer experience, in this case) ended costing more than the problem (password guessing).

The second problem with account locking is that it doesn’t protect against horizontal password guessing attacks.  It’s true that if I decide I want to access Joe Smith’s account and I know Joe Smith’s userID, I can try lots of passwords on his account – and probably get locked out.  But what if I just want to get access to as many accounts as possible?  For example, say the limit for password tries before lockout is 5, I could try 4 passwords on lots of accounts.  If I did this for one day and then waited until the next day to try 4 new passwords on the same accounts, I might have a decent success rate.  And if I’m a smart bad guy and I know the most popular passwords on the Internet (see our earlier blog post on how most bad guys already know this), then I will probably be even more successful.

In security, it’s always important to balance a negative customer experience with the amount of protection  gained.  In the case of account locks, I would say that there is more inconvenience being foisted onto consumers than the security increase warrants.  That doesn’t mean that websites shouldn’t protect against password guessing – they should.  But it would be better to do so in such a way that the system detects actual password guessing and responds to that.  This way the consumer is not inconvenienced and the bad guy is not able to take advantage of the system.