SecMusings

This is another post in the “Unconventional Wisdom” series. I will try not to make it a rant.

Another of those security “rules of thumb” that people accept without a lot of critical thought is the notion that you should lock user accounts after some (small) number of consecutive bad passwords. Auditors, regulators, and (to my surprise) even a fair number of security professionals will cite automated lockouts as a best practice.

In a recent thread on the CISSP® forum, a mailing list comprised entirely of people with CISSP certification, somebody posed the question “where did the standard of 3 attempts come from?” because he had been asked it in a job interview. I was rather appalled at the number of responses that accepted the premise that locking out after 3 tries was a standard.

In fact, locking out after 3 tries is in most situations a really bad idea, and certainly not something you should do without a careful risk assessment. Automated lockouts are meant to prevent password guessing attacks. However, what they really do is deny service to legitimate users and keep your security staff chasing non-events.

As we demand increasing levels of password complexity, and more frequent changes (see spaf’s blog to learn why that is a bad idea) it becomes much easier for users to mistype their passwords quite a few times in a row. After a password change, I’ve been known to fat finger the new one 4 or 5 times in a row. With automated lockouts, I’d be locked out and in need of (costly) service from the help desk. So, for starters, we know that lockouts lead to accidental denial of service.

Even nastier is that lockouts enable a denial of service attack that requires no privilege elevation to mount. This is no trivial concern. In environments without lockouts, DoS attacks against user’s ability to log in are novel enough to be the stuff of tabletop exercises and after-hours discussions at security meetings. These attacks require a lot of privilege to mount, and (fortunately) rogue system administrators don’t come along all that often.

Lockouts change all that — the bar is lowered to the point that anybody with access to your login prompt can mount a DoS attack and keep your users off the air. For example, a disgruntled trader could take out his or her entire trading desk in minutes just before resigning — no privilege or hacking credentials required.

That’s the risk you take on from an automated lockout, especially one with a low threshold. What’s the benefit? I would say little or none. What are the attacks that lockouts are designed to prevent? Most commonly, lockouts are used to prevent password guessing attacks. But let’s think about how password guessing attacks are mounted. They either come from a human user typing guesses or an automated attack.

Human attackers are most likely to use social engineering techniques to get your password. If they are any good, they do not need more than one try. They got your password from you or somebody you trust, either by being plausible on the telephone or by phishing for it with a clever email. A three-strikes lockout does nothing to stop that attack; only good user training will.

Automated attacks come in two flavors, offline and online attacks. A successful offline attack will give the attacker the right password before they log in, so again a lockout does nothing to prevent that attack. The way to prevent offline attacks is to protect your store of hashed passwords so that it can’t be stolen. This means locking down anonymous FTP areas, using shadow password files (or better still, Kerberos) and other means that keep password hashes out of public circulation.

Online password guessing attacks can be stymied by a lockout, but then the attacker knows that you’ve discovered their activities, limiting your ability to investigate the attack and deal with the attacker. My recommended solution is to monitor and alert on failed password authentications. Set a high threshold, say in the hundreds, so that you really know that your are dealing with an automated attack. This will save your response team having to follow up users (like me) with fat fingers and will let them focus their response on attacks in progress.

You will notice a strong bias towards preventing denial of service attacks. That’s because in the industry in which I toiled for 15 years the ability of legitimate users to log in was nearly sacrosanct. The risks associated with having a trader unable to trade on an active day are costly, which means there is a strong bias towards mitigating them. Which gets us back to what I said at the start — lockouts should only be considered after a careful risk analysis. There may be some cases were the DoS risk is cheap and risks that can be prevented with a lockout are higher. In that case go for it, but I’m sure those cases are few and far between. As I’ve tried to show here, automated lockouts don’t really solve the problem that the conventional wisdom intends for them to solve.

Let me just add one more note that may make me seem inconsistent. I do support the feature in portable devices, such as Blackberries, that wipes the device clean after 10 bad passwords. First of all, 10 is a much bigger number than 3 and is unlikely to be a set of consecutive typos. Second, that control is aimed at lost devices, in which case the users have already denied service to themselves, and protecting private data on the device becomes the paramount concern.

But that is the exceptional case. In the end, there is only one word to say in response to a request to implement automated lockouts: “No!”

There was an interesting post on the Security Bytes blog, reminding us that while many attacks are based on user susceptibility, it’s short sighted to just blame the users. While many of us have favorite nasty acronyms to describe our users, in fact, the fact that their behavior enables many cyber attacks is as much our fault as theirs. In many cases, the users have had insufficient training and awareness to know that their behavior is unwise. It is up to us as technologists and security professionals to educate our users.

It is also a big problem that the most prevalent operating system on the corporate desktop (Windows XP) is usually configured so that users have local administrative rights to their workstation. Again, it would be easy to blame the victim, in this case the systems staff, for leaving their users with local admin or power user rights, but the fact is that a lot of Windows applications break if the user does not have elevated rights. I know of at least one company that made a good faith effort to secure their desktop. The number of exceptions that had to be granted, and not just to software developers, was disheartening

The webmasters at Purdue have found the problem with their blog links.  Links in the prior posts should now be working again.

In my first post, I reference a blog post by Spaf on the subject of password security myths. The link is seriously broken. I’ve reported the breakage to the webmaster at CERIAS, but meanwhile, here is a link that will work (based on a search rather than the exact article pointer).