Criticism of PCI password requirements

In my daily job I work with standards such as PCI and ISO27001, as well as numerous other standards and regulatory requirements. Before proceeding, I'll repeat that the opinions expressed here are my own, period.

I saw Ben Rothke being quoted today (Feb 2nd) in this article at GovInfoSecurity.com along with Marcus Ranum of Tenable Security. In the same article there's also Bob Russo, general manager of the  PCI Security Standard Council. Bob Russo is quoted as saying "The standard is solid; there is nothing in the standard which needs change or requires to be addressed immediately". I'm not going to challenge any of them on their opinions in the article, since i fully agree with what they are saying, except the quote from Bob Russo here.

See, I'm doing all this personal research into passwords, and have been doing so for approximately 9 years. I've done penetration tests, security/password audits, consulting, written security/password policies and talked a lot about it to people all over. Here are some of my questions concerning the PCI standard version 1.2.1:

1. Selection of cryptographic solutions vs Microsoft?
 8.4 in the standard says "Render all passwords unreadable during transmission and storage on all system components using strong cryptography". Strong cryptography is defined in the glossary, so I am not going to repeat it here, but it does point to NIST 800-57 for definitions and further explanations on what industry-tested and accepted standards are. I am not going to argue against any recommendations from NIST here.

I don't know if the Microsoft LM hash, and possibly also the NTLM hash satisfies the algorithm and key length requirements set in the standard for protecting passwords. LM/NTLM sure are tested and accepted, but are they good enough given the requirements in PCI and NIST 800-57 for storing (and transmitting) passwords? If not, then Microsoft definitively has some work to do.

2. Definition of "User"
Your glossary has no definition of "User". As far as other definitions tells me, a user is generally a person. Looking at requirement 8.5.3 in the standard, "Set first-time passwords to a unique value for each user and change immediately after the first use." Does this apply to all accounts, or only users? All systems has what i call "service accounts", used by databases, antivirus software, backup applications etc. Without proper service account management, setting a password change frequency policy upon users will only solve part of your security challenges. With more service accounts having administrative rights than administrative users, service accounts are usually a weak spot of any organizations security.

3. Testing procedures
8.5.4 Testing procedure: "Select a sample of employees terminated in the past six months, and review current user access lists to verify that their IDs have been deactivated or removed." Why six months? Why just a sample? I've seen auditors seriously fail on similar testing procedures. I can't see why it should be any problem to verify all user accounts against payrolls or similar information from Human Relations? If there's something most organizations are good at it must be not to pay salaries to people no longer working for them. In fact, i would expect most organizations (at least those working towards PCI compliance) to have such an automated procedure in place before any QSA gets into the process of verification.

Oh, and requirement 8.5.5 says "user accounts", while the testing procedure for 8.5.5 says just accounts. Not too consistent in my opinion, and the same thing applies to other requirements and testing procedures as well.

Some time ago I pulled out a complete listing of users and their associated group memberships (Windows Active Directory) for an organization, and created some simple statistics. An average user was a member of approximately 25 groups, while Domain Administrators had 50-60 group memberhips. The TOP100 however were members of more than 100 groups, and the TOP10 had more than 200 group memberships. None of the TOP10 worked for the organization any longer (most of them were retired). Among the TOP100 were several people who had left years ago, now working for competitors, retired etc. Auditing all accounts is what you should do, not just by selecting a sample of users for your audit. That's just not good enough.

4. What about ROOT?
I'm not sure i understand 8.5.5 "Do not use group, shared or generic accounts and passwords". Are we talking about user accounts (used by people), or service accounts, used by various types of services? The testing procedures are confusing to me, and i do wonder what to do with the ROOT account on my Unix systems?

5. Password change frequency
Requirement 8.5.9 says "Change user passwords at least every 90 days". What about service accounts? What if somebody is sick, travels the world on long-time leave, or as here in Norway; stays home for 1 year on paid maternity leave? What are the requirements for such cases? Your testing procedures only requires inspection of written and/or technical parameter settings, there is no requirement to do even samples of "password last set" timestamps. If you did, you would probably be surprised in any organization.

6. Minimum password length
Requirement 8.5.10 says "Require a minimum password length of at least seven characters". A lot can be written on this topic, but for your testing procedures you are referring to sample audits on documentation and system inspections, and only asking for documentation on this from service providers (no system inspections). For a general policy you will only have one change frequency requirement, but in real life it will be different from system to another. The frequency applied on users of course has its limits in common sense and usability, but for service accounts the policy could, and should, be stronger. This setting is also heavily dependent upon the selection of cryptographic solutions for protecting your passwords, especially in the event of offline attacks. If you are using Microsoft Windows LM, NTLM or unsalted MD5, your password length should be at least 9 to reduce the risk to what i would consider acceptable risk - and that is today. Thinking about what tomorrow might bring along, i would go for length 10 immediately, and compensate users with a longer change frequency policy.

In any way, your minimum requirement of length 7 is one short of what many others recommends as the absolute minimum today (length 8).

7. Password complexity requirement
Requirement 8.5.11: "Use passwords containing both numeric and alphabetic characters". Just as the minimum length above, there are many opinions on this requirement as well. However the general recommendation by most is requiring users to use at least 3 out of 4 character groups: UPPERCASE, lowercase, numeric and special characters. Based on my own research approximately 50% of users end up with first character being uppercase, rest is lowercase and numeric. Still, such a requirement does create better entropy with case-sensitive passwords.

It is very rarely that i come across systems where there are no accounts with the password being the same as the username, or with the username being the start and dominant part of the password. As long as the username is "complex", such as user1@hotmail.com, the same can be used as the password and in compliance with the PCI requirements. Probably not the intention of PCI, and most definately not a good idea for any system. Setting proper complexity requirements is not easy, and for end-users a password policy really should be short and simple. Do not create a 4-page policy, make it 4 sentences, tops. Then set your technical complexity requirements, and if anybody asks why they can't use password1 as their password, tell them there's a secret complexity requirement, please try again with another password. (Oops: password1 is actually good enough according to the PCI length and complexity requirements!)

Additionally your testing requirements are similar to that for password length, they are not sufficient in my opinion. I won't promote any specific services or products here, but QSA's can easily and quickly do sample checks or even full account database audits to ensure 100% compliance. Your testing procedures is that of standard auditors, they simply will not document much real-life security compliance.

8. Password history
This is a policy option that connects with the change frequency setting. The requirement is "Do not allow an individual to submit a new password that is the same as any of the last four passwords he or she has used". Here you specifically refer to people, not any type of service or other non-personal accounts. I can't understand why this requirement shouldn't apply to such accounts as well?

I have earlier written a blog entry entitled "Why history may be bad for you". No, I'm not advocating for removing the history parameter, i prefer the general recommendation of setting this to at least 13, to avoid the use of days and months as the main parts of passwords. However this also increases the risk of never being able to recover from a partial or full compromise of an account database. This should be reflected in the risk analysis before setting the password policy and selecting cryptographic solutions. Reading Thomas Ptaceck's blog post on secure password schemes is highly recommended!

--

My earlier comments on the testing procedures applies to several of my little objections in this blog post. Auditing a "sample", even without any definition of what or how much a sample is, it represents a risk for the QSA, the customer and of course: the end user.

I have no problem accepting the role and responsibility of any organization seeking PCI compliance, with the QSA not being responsible in any way for bad security. Economical fact; most organizations will use the cheapest available QSA, as long as they are approved by the PCI Security Standards Council. The QSA, in order to stay competitive, must provide the cheapest possible service while maintaining their bare minimum requirements. The keyword here is MINIMUM. Still we do expect security to be better than the minimum, don't we?

Marcus Ranum is quoted in the article as well, saying that "...PCI is a minimum baseline requirement toward security, and companies just cannot afford to focus on PCI alone in being secure".

A statement which simply summarizes this blog post.

Personally i think that PCI definitely has room for improvements to become even more specific in its requirements to avoid confusion and misunderstandings, and that also applies to the testing procedures for QSA's. As for the quote from Bob Russo on "The standard is solid; there is nothing in the standard which needs change or requires to be addressed immediately", i looked up the word "immediately" on Wikipedia, and found this among the other definitions: "such convenient time as is reasonably requisite for doing the thing."

I look forward to the next version of the PCI standard.