It’s Impossible to Make Anything Foolproof, Because Fools are so Ingenious

Security is a key component of many modern computer systems and our Customer Interaction Center (CIC) solution is no exception. Sadly, too often we in the IT world don’t really understand the entire security issue, and as a result, produce a system that is easily compromised. There are two components to consider for good security – the technology and the people. If we don’t consider the latter and make their lives easier, they will take steps to work around the technical measures we put in place.

In this post, I want to focus on a single security setting, the number of incorrect login attempts that should be allowed before an account is locked. In future posts, I will focus on other settings. In CIC, this is configured as part of the Password Policy.


Ask most people what they think the setting should be for the number of login attempts, or what the setting is in their system, and you will usually get answers ranging from three to six. Is this reasonable? According to the National Institute of Standards and Technology in their paper Guide to Enterprise Password Management this number is too low. Yes, you read that right, way too low.

They suggest that a much more reasonable number is 50. Really?! Yes, really! Think about it:

  1. In a password space of many billion, the percentage difference between 3 and 50 is negligible. With a standard alphanumeric 8-character passwords, even without special characters the password space is 218340105584896, meaning 3 represents a paltry 0.000000000001274% and 50 only 0.0000000000229%! Even with an 8-digit numeric PIN (such as we would use with CIC) 3 is 0.000003% and 50 is 0.00005% of the available 100,000,000 possible passwords. The increased risk of someone guessing the password is insignificant. Is 50 really that greater a risk?
  2. If users know they have many, many attempts to try their password, then they are more willing to use different passwords for different systems. They know that the password is one of 10 or 20 they typically use, so if they can’t remember, they can just try them all!
  3. If the users are worried about forgetting, or mistyping a complex password, they won’t use one if doing so is likely to cause their account to be locked.
  4. Even if we manage to bully our users into dealing with points 2 and 3 (above), they may be so concerned about forgetting their passwords that they write them down. Visit any office and you will find a note in the corner of the monitor, or under the keyboard, or under the telephone with a password written on it. Is that secure?
  5. Security isn’t just about preventing unauthorized access, it is also about guaranteeing authorized access. Setting an incorrect login attempt too low, will increase the frequency of lockouts. While waiting for their account to be reset (either automatically, or following a help desk call), users have no access. This will cause them to be unable to perform their job. What is the cost to the business of this? Furthermore, keep the login attempt too low, and you could be putting the company at risk for a security breech known as a Denial of Service attack. Having a low number of incorrect logins allowed means that anyone wishing to launch this type of attack could lock many accounts in a relatively short period of time.

In my opinion, we need to educate our users and work with them, not against them. Part of that is to make it easy for them to do what we want them to do. Like the title says, “It’s impossible to make anything foolproof, because fools are so ingenious.”

Please comment back with your take on this.

In my next post, I will take a look at password complexity.

Paul Simpson

Paul Simpson

I joined Interactive Intelligence in January 2008 as a Training Consultant in the Education Department. Based initially in the Amsterdam office, I transferred to Indianapolis in 2010, where I still work in Education. My formal areas of interest are Interaction Dialer and Interaction Process Automation, however I can usually be found experimenting with various abstract parts of the product and love to make it do cool things! I’m always playing around with scripting and automation. Anyone who has attended one of my classes will tell you that my theories of troubleshooting can involve chickens and I am passionate about the correct pronunciation of the word “router.” Prior to Interactive Intelligence, I worked as a school teacher (mathematics and computing), a network engineer (mostly Novell), a hardware support engineer and a developer. I can trace my computing history back to the days of the Z80 and 6502. I have a keen personal interest in home media and automation. I am also developing an interest in Animatronics and would like, one day, to create a haunted-house walk-through for Halloween. I can be quite opinionated and hope that my blog posts will spark some healthy debate.