Why “3 tries and you’re locked” *weakens* security

Some organisations have a security policy that after three failed authentication attempts an account is locked (requiring manual unlocking by an IT support person) – the goal is to strengthen security, but this actually decreases the security of the organisation.

The intent of a policy like this is to prevent brute-force attacks – if you’re limited to three attempts per account before intervention by a human is required, then brute-forcing an account is no longer practical.  However, there are better ways of preventing a brute-force attack, for example:

  • With each consecutive failure, suspend (stand down) the account for a small, but exponentially  increasing amount of time.  For example, after one failure, suspend for 0.5 seconds, after two failures 1 second, three failures 2 seconds, and so forth.  Even just doubling each time means that after 20 consecutive failures you have to wait 12 days before the next attempt.  Brute-forcing is no longer practical – however, no human intervention is needed, and the penalty for the first few failures are not even noticed by the user (because, unlike a script, they are unable to re-attempt in under a second or two).
  • After X consecutive failures, require additional credentials to log in.  For example, many web sites will require a CAPTCHA; although these are breakable programmatically, the resources required for brute-forcing increase significantly.  Other credentials can also be used (additional security questions, two-factor authentication, and so forth), depending on the organisation.
  • Ignore duplicate password attempts (i.e. if the user tries the same password twice, that’s only one failure).  That clearly isn’t a case of a brute-force attempt, it’s someone thinking they mistyped their password.
  • Allow for some sort of password hint (this is of no use to someone trying to brute-force, but it potentially opens more social-engineering vectors, so should be used with caution).  Even without a user-specific hint, the system can provide its own hint about what is required (e.g. “don’t forget that you must have upper and lower case letters and a number”), which may help trigger the user’s memory.
  • Allow “trusted” users to unlock other users (e.g. in an educational institution any staff member could unlock any student account); who does the unlocking is (of course) logged for auditing purposes.  The trusted users should be those that can be relied on to not have their account foolishly compromised.

So it’s clear that there are better ways to do this – but how does this decrease security?  It opens an extremely trivial vector for denial-of-service: essentially the same brute-force script can be used to make three random attempts on nearly every account (usernames are typically easy to formulate – an educational institution typically uses numbers starting with a year for students, and some sort of first name + last name combination for staff, for example).  This immediately locks every account in the system, requiring human intervention.  Writing a script to do this is extremely simple.

Even if there is no malicious intent, this can be done without any scripting at all by a mischievous user (extremely common in, e.g., educational institutions), by picking one or more usernames (it’s likely that the user knows or can easily find usernames of anyone that they wish to annoy) and simply making three manual attempts.  If this done from a shared system, then (given that this is the log-in process), it’s likely that there is no way to track this behaviour.

There are other flaws with this approach, too:

  • The user working after hours who accidentally locks their account is locked out until IT support working hours resume.
  • The IT support staff have (should) have more productive ways to spend their time than unticking a box.  (Sometimes there’s a way to unlock that requires going to a physical location, but doesn’t require assistance from a human.  This just wastes the user’s time, not the support staff as well).
  • Vertical brute-force attacks are prevented, but horizontal ones are not (unless another system is used as well).  Every account in the system can be attempted twice without causing locking (assuming an insignificant number of previous failures).  Given a sufficiently large number of users, it’s likely that an attacker can select two potential passwords that have a high probability of use (e.g. the default password and a “1” at the end, “password”, “P4ssword”, etc), because it’s proven that users typically use the weakest passwords that they are able to .  If access to a single account the goal, rather than a specific account, then two high-probability passwords can be attempted each day (assuming a high likelihood of a successful log-in attempt each day).  The system needs to at least only lock the account for attempts from the authenticating system (e.g. IP).
  • Three attempts is an arbitrary number (likely selected because of use in other systems, like debit card PINs) that is typically insufficient.  The first reaction of nearly any user on a failed authentication attempt is to assume that they made a typing error entering the password – if that’s not the case, then there’s only a single attempt left.  The user is now left with the dilemma of what to use as the final attempt – was it two typos? Was it one of these other two passwords? Was it this password that just expired and I had to change?  Allowing five or even ten attempts does nothing to reduce the (limited) effectiveness of preventing brute-force attacks, but makes the experience significantly less problematic for the user.
  • If the password is used for more than logging in to a system (e.g. it’s used for a network proxy), then authentication is likely to be attempted by an automated system (i.e. saved passwords).  The stored credentials will eventually be wrong (when the password is changed, which may occur within a few weeks if there is an overly protective expiry policy), and the user is unlikely to remember everywhere that they are stored.  Software is likely to automatically retry after a failure, possibly after an extremely short (from a human point of view) amount of time, which means that the user will have their account “automatically” locked, often (ironically) simply by logging in.  Given that authentication generally only requires the username and password, it’s quite difficult for a user to identify what software is incorrectly trying to authenticate.  (Note that this is potentially also a problem with suspending an account, especially with software that very aggressively retries).

If your organisation uses this extremely flawed system, please consider changing it for something more effective.

Advertisements

3 responses to this post.

  1. Posted by Ben on May 3, 2011 at 11:02 pm

    Think you can get NorthTec to change their system:) Maybe you can point this page out to ICT.

    It actually surprises me that students don’t lock their tutors account out of malice as they often see the tutor’s log-in on the OHP.

  2. Albert asked the tutors for a list of any “fixable” complaints to see if they could be fixed, and I did mention this. I would put the odds very low that anything will change, but it’s not impossible.

    I’m surprised there isn’t more malicious/mischievous lockout behaviour too (maybe there is, and I just don’t know about it). Isn’t the tutor username the same as the tutor’s email address? So if a tutor annoys you, you just try three times with their username next time you’re in the library. Seems next to impossible to catch.

  3. Posted by Ben on May 4, 2011 at 6:00 pm

    Yeah I doubt anything will change. If they have to use the lock-out policy they should at least make it ten attempts or something decent. And the three month expiry policy is especially ridiculous – I think it should be indefinite but if they can’t handle that then at least give it a year.

    You are right about the tutor username. One tutor has told me that he has been amazed that he has never yet had a student do it to him.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: