Password Policies

While this has been in process for a while and the guidance has been out for a while, the guidance NIST published in June related to identity management seemed long overdue. For me, this came to a head a few years ago with a client I was working with. They had the then-recommended (best practice to the rescue again) password policies in place. Strong passwords — letters, numbers, different cases, symbols, appropriate length. Passwords rotated every 30 days. No repeat password before 12 passwords had been reused. At least 7 days between password changes. Strong password policy, right? What I told them at the time was they were begging their users to write their passwords down just to keep track of their current one. That, of course, entirely defeated the purpose of the password policy to begin with.

What was even worse was that the administrators and management of the company I was working with had no idea what the purpose of the password policy was to begin with. What exactly is the purpose of rotating passwords and making sure they are incredibly complex? For a start, you make the complex so they can’t be guessed. Unfortunately, with so much horsepower readily available and with rainbow tables so easy to get hold of, even complex passwords that are 8 characters (a common minimum) may be easily cracked by a determined attacker. That’s why you have complex passwords — to make sure they can’t be guessed or determined in a brute force attack. Since it’s possible to crack them anyway, that idea is a bit behind the time.

The reason for rotating them is based on an assumption that someone is getting in using the password. If you rotate the password on a regular basis, you limit the amount of time that an attacker can stay in your system. The assumption also was that with a regular rotation scheme and lower horsepower systems, it could take as long as the rotation time to crack the password. Ultimately, it was about limiting potential access using the password. The reality is that attacks and access are far more likely to take place using social engineering attacks or other ways of gaining access without needing the password.

One of the reasons for writing this up was reading Bruce Schneier’s Crypto-Gram e-mail from this month. He quite rightly points out that the idea of password policy stemmed from attempts to try to fix the users rather than trying to actually resolve the problems that existed. As a result, we as information security professionals have spent a lot of time trying to enforce and detect lapses in security policy compliance.

This is yet another example, to me, of the solution coming before the problem. Without really understanding where the threats were (what the problem was), there was a drive to implement password policies. Worse than that, when businesses implemented strong password policies, they felt they were protected against attack. The reality is that they were left exposed because they had no idea what problem they were trying to solve and they spent time implementing and enforcing password policies rather than truly understanding where their threats and exposures were.

This is a soapbox I get on a lot. It is absolutely essential that time is spent defining and understand the problem to be solved in order to make sure that when a solution is arrived at, it is the right solution and not a red herring that makes people feel like they’ve done something.