So far, in my mini-series on security, I have examined incorrect log on attempts and so called strong passwords. This time, I want to turn my attention to password change policies. Unlike my previous posts, I am not going to quote facts and figures, or even make suggestions. I am merely going to give you some things to think about.
Once again, I should point out that I am not, in any way, suggesting that security isn’t vitally important. It is. However, I passionately believe that it is more about user education than draconian measures. As my first blog title stated, “It’s Impossible to Make Anything Foolproof, Because Fools are so Ingenious.” Too often, we are trying to come up with a technical solution to what is, essentially, a social problem!
Anyway, on to password change policies. The question we need to ask ourselves is, “Why do we make our users change their passwords every x days?”
The obvious answer is, “In case someone has discovered it.”
Let us assume for a moment that we have a password policy requiring at least eight characters, using mixed case and at least one number. Reviewing what I said last time about password strength, users typically put the number at the end. Why does that matter?
Well, let’s take a user with a current password of Password1. This meets our strength requirements. Let us further assume that this password has been compromised and is being used for nefarious purposes by someone else. “No problem,” you say, “our password change policy deals with that issue!” Really? So, the user is asked to change their password, which they do. How long do you think it will take our hacker to guess the new one once they realize it’s been changed?
Next, we need to consider the frequency of changing. Be honest, how many of you opt for frequencies of 60, 90 or 180 days? Awful, I say! These are all multiples of 30, which is about a month, which means that a significant number of people are likely to use the date (at least the month and maybe year) in their password.
Taking a step back, what do we really want to achieve?
Ideally, we want users to select secure passwords. But forcing them to come up with a new one every few days is surely not helping them to do this? Also, remember what I said in the first article. If you have complex passwords and a low number of logon attempts allowed, users are more likely to use the same password for multiple systems. You don’t want this. But if they then have to change their password periodically on some of those systems, the passwords get out of sync. Which doesn’t help your users at all!
I know I said I wasn’t going to make suggestions, but here is an idea for you to think about. Force passwords changes periodically, but allow password reuse. That way, users are reminded to think about their password every few weeks, but if they consider it still to be a good one, they can change it back to what it currently is.
Once again, I welcome your thoughts on what, for some, are my rather provocative views!
Until next time, when I plan to look at “The Onion” nature of security…