Passwords are critical security barriers between controlling access and letting anyone run ragged over your network. Because the uses of passwords and the protections surrounding them have changed dramatically over the years, every organization seems to have a different password security policy
Rather than cut and paste a 13-year-old policy you found on a government website, it makes sense to think about what goes into a good password security policy and why you should put it there.
A password security policy is there to reduce risk, which means organizations can only write a good policy by thinking about the risk they are trying to reduce. Of course, you can always say to yourself, "I won't think about risk; I'll write a policy with overkill." That has two problems: the first is that the more difficult the policy is to understand or comply with, the more likely users are to work around the policy. So by making an insanely "overly secure" policy, you're actually giving people a reason to act insecurely.
The second problem with overkill policies is that they indicate the information security staff isn't doing its job. If IT teams won't look at security risks and try to find appropriate compensating controls with something as simple as a password policy, how can they expect anyone in the company to respect IT's professional judgment about other areas of information security?
The risks of implementing a poor password security policy
Let's look at risks in a little more depth to see how password security policies should reflect the risks to the organization. Your three biggest risks with passwords are intentional password sharing, password theft or loss, and password guessing. People sharing passwords to get their jobs done (and sometimes for other reasons), and then not immediately changing them is one bad practice, but passwords also can make their way into the wrong hands through theft: shoulder surfing, social engineering, sticky notes on people's monitors, password reuse across systems and websites, poorly-designed password reset procedures, and so on. And, of course, passwords can also be guessed, either through brute force (trying every possible password option) or through clever and directed guessing.
Most password policies, though, focus entirely on mitigating password guessing, paying little or no attention to anything else. One reason security managers tend to ignore many significant risks associated with passwords is that it is much easier to implement technical controls than human controls. In most operating systems, for example, you can set password history and change frequency and complexity requirements. But there's no registry key that helps educate people on how to avoid shoulder surfing, or reminds them never to type their password using someone else's computer.
The more difficult the policy is to understand or comply with, the more likely users are to work around the policy.
Even the risks associated with password guessing are often misjudged. For example, if you have a well-designed authentication system with break-in evasion capabilities, then the risk of someone brute-force guessing a user's password is almost zero, unless the user has chosen the most obvious password possible. This is because after a handful of tries, break-in evasion will kick in and prevent even the correct password from working, hence guessing the password immediately becomes impossible because the attacker will never know when he or she guessed the right one. In this case, your password complexity requirements can be simple and provide effective protection.
On the other hand, if you don't have break-in evasion, or if your authentication has some "back doors" that bypass the break-in evasion, such as an FTP server or a webpage that uses authentication, then brute-force attacks are likely, and more complicated passwords are needed. Brute-force attacks are also an issue if your password file (or security database) is ever exposed; the simpler the passwords are, the more quickly an attacker can regenerate them.
As you build your password security policy, consider the risks involved with passwords, and write a policy that appropriately compensates and controls those risks. At the same time, remember that the most effective policies are those which are backed up by strong user education and frequent testing to help evaluate compliance.
About the author:
Joel Snyder is a senior partner at Opus One, an IT consulting firm specializing in security and messaging.
This was first published in November 2010