Passwords don't work. Users aren't creating secure enough passwords. Users are writing their passwords down. Management is ignoring the fact that we have a password problem. Management refuses to enforce any password policy we put in place.
Do any of these sound familiar? I'd be willing to bet you've come across all of these issues at some point or another. I'm even willing to bet you're fighting some if not all of these right now. Well, don't fret -- you can do something about it.
The answer lies in how your organization deals with computer password policies. Some password policies are good but most are inadequate. In the name of convenience and to keep employees off of executive's backs, I often see users who are not required to have complex passwords. On the flip side, in the name of "security" I see users who are required to change their passwords really often -- like every 30 or 60 days. Both of these common practices can be bad -- really bad -- for your network's health. What these policies breed either weak or written down passwords. I have even seen passwords as text on a user's marquee screen saver!
An ideal password policy is to require complex passphrases 10-15+ characters in length that would be extremely difficult for anyone to guess yet very easy for employees to remember. This could include such passphrases as:
- Itz_COLD_Outside! [read/remembered as It's cold outside!]
- My Sekyur P@ssword. [read/remembered as My secure password.]
- Fast_C@rs! [read/remembered as Fast cars!]
Simply show your users how this can be done -- you'll undoubtedly be amazed at the lights that go off in your user's heads when you demonstrate how much sense this makes. A little enlightenment goes a long way. I challenge you to try it.
A positive side-effect of such a policy is that you won't have to force your users to change their passwords every 30-60-90 days. Unless there's a reason to believe that a password has been compromised, only require users to change their passwords once a year -- if that.
This can all be enforced via Local or Group Policy for Windows-based passwords. Combine these settings with the requirement to use NTLM-based passwords where possible and I guarantee you this is all you need for 99.99% of your Windows-based systems. Once you help establish a culture of passphrases, people can start to understand why they need to use them in other areas such as applications, databases, zip files, what have you. Oh, and don't forget about your switches, routers, firewalls, wireless access points, and other network devices either.
Prove the need for better policies
If you can't seem to get the point across to upper management that a password problem does exist, there's still hope. I've found that using a password cracking program such as Proactive System Password Recovery to search for insecure Windows-based passwords stored on local systems, Proactive Password Auditor to root out weak Windows domain passwords, and Brutus for public-facing Web, e-mail, FTP, etc. apps is very effective in showing there's a password problem. Run these tools (as an untrusted outsider or internal user with limited rights where possible), take screen captures of what you find, document your findings in a professional looking report, and share your findings with management. If you uncover password vulnerabilities, it'll be hard for them to argue with the facts.
Formatting, managing and enforcing the policy
Don't stop at your policy requirements either -- formatting, management, and enforcement are just as important. Keep the following in mind when creating or updating your password policy:
- Your policy should be clear and concise such as 10-15 characters formatted as phrase or acronym changed once per year or until compromise is suspected or discovered.
- Specific password risks need to drive the policy based on your organization's business needs -- simply copying and pasting someone else's policy off the Internet is not enough.
- Roles and responsibilities (who's doing what) and compliance metrics (how and when testing will be performed) must be defined.
- Sanctions need to be clear so everyone's expectations are set regarding what happens when the policy is violated.
- Enforcement needs to take place consistently by an IT governance committee consisting of HR, legal, information security, and management -- not just the IT or information security department.
Remember a password (or better yet, passphrase) policy is a document that should state "this is how we do it here". If you need to have exceptions, that's okay. Just make sure you document your exceptions within the policy itself either in the Scope or a dedicated Exceptions section. The most important aspect is to focus on education and balancing security and usability. When you strike this balance, you'll have the most secure systems and happiest users. What more could you ask for!?
For further reference, this e-mail policy template provides a good starting point for formatting your password policy document and ensuring the right information is included. If you want to learn more about effective security policies, check out this FAQ and the webcast How to create practical and effective e-mail security policies. These resources focus on e-mail but the subject matter can be directly translated to password policy concerns.
If all else fails -- it may be time to consider strong authentication -- a different solution with a whole new set of issues.
ABOUT THE AUTHOR:
Kevin Beaver is an information security consultant, expert witness, author and professional speaker at Atlanta-based Principle Logic, LLC. With over 23 years of experience in the industry, he specializes in performing independent security assessments revolving around minimizing information risks. Beaver has authored/co-authored 10 books on information security, including The Practical Guide to HIPAA Privacy and Security Compliance and Hacking For Dummies. In addition, he's the creator of the Security On Wheels information security audio books and blog, providing security learning for IT professionals on the go.
This was first published in November 2008