At the heart of compliance is access management and authentication. And at the heart of authentication are user IDs and passwords. Despite their many weaknesses and the availability of multifactor authentication technologies, the venerable user ID and password combo remains the centerpiece of access to many corporate systems.
Rather than tearing up network plumbing for new-fangled devices, like one-time password (OTP) tokens and smart cards, many companies have opted to strengthen their existing password systems to keep compliant with audit and compliance regulations and standards, including Sarbanes-Oxley, HIPAA, FFIEC and PCI DSS.
In this tip, we'll take a look at the password requirements for each of these regulations and standards and offer some best practices and tools to enforce password compliance.
Passwords and standards
Let's start with the Sarbanes-Oxley Act (SOX). Its Section 404, which deals with access management, is vague and without specific requirements, saying that access controls must be adequate to enforce the financial controls required by Sarbanes-Oxley.
Nonetheless, Sarbanes-Oxley experts and auditors recommend that to meet the minimum for compliance, passwords should:
- Be at least eight characters long;
- Include a combination of letters and numbers;
- Not contain personal information, such as the names of spouses or family members (including pets!), or any information that an attacker could easily derive from a user.
Similarly, HIPAA doesn't call specifically for passwords to be used to protect patient information. But, as with Sarbanes-Oxley, auditors recommend similar best practices for passwords. They should be a minimum of six, preferably eight, characters in length, and a combination of uppercase and lowercase letters, mixed with numbers and symbols (!, @, #, $, for example).
Passwords should be changed every 45 to 90 days and should be different every time. They shouldn't be changed just by incrementing a number at the end or by adding a new character. A password like "bobsmith14" shouldn't be allowed to be changed to "bobsmith15" at the next go-around. And, of course, like Sarbanes-Oxley, no names of kids or family members, or any dictionary words, should be allowed.
The purpose of making passwords more complex and indecipherable is to prevent so-called dictionary attacks, where hackers run password hash files through programs like "John the Ripper," which look for common words in dictionaries used as passwords.
Probably the most prescriptive password requirements come from Payment Card Industry Data Security Standard (PCI DSS). The standard calls for all system users to have a unique ID. In particular, there are four strict requirements: passwords must be changed every 90 days; have a minimum of seven characters; have a mix of both letters and numbers; and can't be the same as any of the user's last four Passwords.
The Federal Financial Institutions Examination Council (FFIEC) standard, on the other hand, doesn't have any requirements for passwords, but recommends supplementing them with two-factor authentication for Internet banking.
Password compliance best practices
With all these different requirements, what are some best practices and tools for enforcing password compliance? Here are some recommended practices to cover most regulatory bases:
- Passwords should be at least eight characters long. Those characters should include both letters and numbers and, of the letters, both uppercase and lowercase.
- Better yet, encourage users to create passphrases, which are easy to remember and can be telescoped into a complex and hard-to-beat password. For example, a user might turn "My dog Rover is the greatest pet" into "M7dRg8pt."
- Passwords should expire at least every 90 days.
- Password should not contain more than three consecutive letters from the user ID.
- Users shouldn't be allowed to reuse any of their last four passwords.
So, should these rules be enforced? What tools are out there? If you're using Active Directory and LDAP, the tools you need are already at hand. Most likely, you're already using one or the other, or a combination of both. Even if you're using some other front-end access management product, like IBM Tivoli, Citrix or Sun Microsystems' Java System Identity Manager, the directory server on the back end is still probably Active Directory, LDAP or both.
With LDAP, it's possible to set a minimum password length, minimum number of alphabetic and numeric characters, number of repeat characters and the number of characters which must be different from a user's previous passwords. Group Policy Objects (GPO) in Active Directory does all of that, and can be set to prevent a user from reusing up to 24 of his or her last passwords, force password resets after a set interval and require passwords to be complex with a combination of numbers, and uppercase and lowercase letters.
And, since both Active Directory and LDAP integrate with third-party access management provisioning tools just mentioned, password compliance doesn't have to be another one of those dreaded compliance headaches. Thanks to some built-in capabilities, it should be easier than you think.
About the author:
Joel Dubin, CISSP, is an independent computer security consultant. He is a Microsoft MVP, specializing in Web and application security, and the author of The Little Black Book of Computer Security available from Amazon. He also has a radio show on computer security on WIIT in Chicago and runs The IT Security Guy blog at http://www.theitsecurityguy.com.
