Security vs. Compliance with PCI DSS Requirement 8

August 4, 2020 • Published Categories Best Practices Tags , ,

A few weeks ago I was talking with one of my coworkers about the whole security vs compliance conversation. Up until then, I held the premise that compliance does little for security. In retort to my statement he asked the rhetorical question, “Where would these companies, from a security perspective, be without compliance?”

Yes, compliance is the minimum that you need to do to defend against attack; however, if you are going to complain about having to do compliance then there is nothing preventing you from focusing on stronger IT controls.

In this blog post, I want to take a moment and discuss some of the missed nuances of PCI DSS Requirement 8, which is essentially focused on password management; but, often argued is not secure enough. There are often a few overlooked pieces of information provided there that I’d like to shed light on. And, in staying with the theme, if these controls are not strong enough, feel free to increase the level of control.

The Finer Points of PCI DSS Requirement 8

When we examine the preamble to section 8 of the PCI DSS, it defines the applicability of this requirement. What is interesting is that these password requirements do not apply to all users, even though many assume it does.

Here is that text contained in the note section of the preamble:

Note: These requirements are applicable for all accounts, including point-of-sale accounts, with administrative capabilities and all accounts used to view or access cardholder data or to access systems with cardholder data. This includes accounts used by vendors and other third parties (for example, for support or maintenance). These requirements do not apply to accounts used by consumers (e.g., cardholders). However, Requirements 8.1.1, 8.2, 8.5, 8.2.3 through 8.2.5, and 8.1.6 through 8.1.8 are not intended to apply to user accounts within a point-of-sale payment application that only have access to one card number at a time in order to facilitate a single transaction (such as cashier accounts).

In short, there are numerous password requirements that do not apply to individuals who handle one card at a time, such as a cashier and interestingly, even possibly call center staff. If the staff member only has the ability to enter cardholder data and cannot view it, from an application perspective, then there are several controls that are not applicable. This is an area where you can go above and beyond to increase your security posture. Where you are able, ensure that these controls are implemented for all individuals.

While not a requirement of the PCI DSS, I recommend that you take the time and perform a formal risk assessment. This will ensure that not implementing these controls for that type of account does not cause undue burden to your data. You can also go above and beyond and establish controls for the aforementioned types of user accounts that it does not apply to.

Setting Password Criteria

Next, we have language within the Guidance section of Requirement 8.2.3. Specifically, 8.2.3 states:

8.2.3 Passwords/passphrases must meet the following:

  • Require a minimum length of at least seven characters.
  • Contain both numeric and alphabetic characters

Alternatively, the passwords/passphrases must have complexity and strength at least equivalent to the parameters specified above.

And the Guidance section of this requirement states:

This requirement specifies that a minimum of seven characters and both numeric and alphabetic characters should be used for passwords/passphrases. For cases where this minimum cannot be met due to technical limitations, entities can use “equivalent strength” to evaluate their alternative. For information on variability and equivalency of password strength (also referred to as entropy) for passwords/passphrases of different formats, refer to industry standards (e.g., the current version of NIST SP 800-63.)

So what does this all mean? Let me start by saying a 7-character password can be compromised in no time at all if the hash has been captured. If you are not aware of what that looks like, take some time to research Rainbow Tables.

I personally recommend passwords of at least 15 characters. The reason there is only a requirement of 7 characters is that the PCI DSS has to accommodate legacy environments and systems. Is 7 characters secure? I will let you make that decision. But where your systems can support more, there is nothing that prevents you from requiring 32 characters.

What if your password is comprised of 32 “1’s”?  Let’s calculate the password entropy of what is required. If your password is 7 characters comprised of alpha and numeric values, http://passwordstrengthcalculator.com reports that it would take less than a second to crack the password with a super computer with 36.2 bits of entropy. Whereas a password with 32 1’s would take 15,854,896 years with the same computer with 106 bits of entropy.

So, it’s not just about the password make up. There are a numerous values that can impact a password; however, it’s not about doing the minimum, it’s about doing what is necessary to protect your assets from unauthorized attack.

While compliance does not equal security, you do not have to do the minimum. Do your risk assessment and if an asset is still at risk, even with the minimum requirements, it is within your liberty to increase your security posture and require more than just the compliance standard.  Every company who has ever been breached was complaint with something. However, they were not secure. Focus on security, and compliance will normally happen as a biproduct of being secure.

Hopefully the tips I’ve provided here will help set you on the path to compliance with PCI DSS Requirement 8. Click here to view my other PCI Compliance Guide posts.