Why You Need Intruder Lockout

It’s a very predictable web security flaw — in fact, it’s something I find in the majority of my web security assessments: the lack of intruder lockout on login pages. I know, with all the SQL injection and cross-site scripting present on the web, the lack of intruder lockout on web login pages seems a bit trite. Given what this vulnerability can lead to, I believe it deserves more attention.

Keep in mind that I typically classify the lack of intruder lockout on login pages as a “medium” priority issue. You’re not bleeding at the moment but — instead — several things have to fall into place for the attack to lead to something bad; including accounts with weak passwords and lack of system monitoring and alerting. There are so many web security variables at play here. In many cases, the different controls need to work in conjunction with one another – especially as it relates to protecting the login mechanism.

So what’s the ideal setup for intruder lockout? Well, every situation is different and every business has its own unique needs. That said, I often recommend locking accounts for certain period of time (i.e. 5-10 minutes) after 5-10 failed login attempts. You may also use some form of automated password reset logic in conjunction with this process. Even something like tarpitting failed login attempts (i.e. purposefully slowing them down) can be beneficial as long as the delay is reasonable or the accounts are eventually locked.

Enabling intruder lockout is a relatively simple fix given what’s at stake. Whether you’ve got basic HTTP, forms, or some type of multi-factor authentication, keeping track of login abuse can have great payoffs — especially given the bad choices people make regarding passwords. Granted, intruder lockout could have the reverse effect on security. If you’ve got an attacker with a set of legitimate user accounts (often email addresses which can be relatively easy to obtain), then he could conceivably attack accounts via login pages that have intruder lockout enabled and effectively create a denial of service situation. You’ve got to determine what the greater risk is – password cracking or potential denial of service.

In many situations, intruder lockout on web login pages can eliminate a considerable amount of risk – especially in situations where you offer a SaaS/cloud solution and you’re not at liberty to control the enforcement of certain things like password complexity. Do what you can to set your users up for success. Even if they choose to use weak passwords, intruder lockout will at least help minimize the risk of successful password cracking.

Share this post

Leave a Reply

Your email address will not be published.