PCI DSS 3.2 Multi-Factor Authentication Clash

Recently the PCI Security Standards Council held their North American Community Meeting.  This annual meeting brings together assessors, payment professionals, card brands, Council members, Acquirers, and other interested parties to discuss the state of our beloved PCI DSS and associated standards.  This year had a surprising amount of drama.

One of the more contentious discussions I observed was regarding multi-factor authentication (MFA).  In my opinion, this should not be a contentious issue.  MFA is a mature technology with wide acceptance. However, the PCI DSS had a significant change recently regarding MFA that incited a lot of discussion.

What Do You Mean, MFA?

With the 3.2 standard, a new 8.3.1 requirement was added that states:

“Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access.” 

Superficially, this is fairly self-explanatory: all administrative non-console access to the CDE must use MFA, regardless of if they are connecting from the LAN or the internet.  I consider this a requirement where the intent is clear.  Use of MFA makes stolen credentials less dangerous reducing the likelihood of unauthorized access to CDE systems.

When the topic of what multi-factor authentication really means, the drama began.  From our perspective, this was a classic clash of theory versus reality.

The discussion started, innocuously, with the question of what constitutes two (or more) factors of authentication?  The standing definition from the PCI DSS is that you must have at least two of the following: something you know (a password); something you have (a token); something you are (biometrics).  Again, difficult to find controversy here.

The shouting erupted when the discussions turned to the concept of “independence” in authentication measures. Specifically, one of the speakers cited NIST Special Publication 800-63r2, Electronic Authentication Guideline (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-2.pdf) as the definitive guideline for this.

The speaker was adamant that two-factor mechanisms must be wholly independent from the device that accesses the environment.  Since many two-factor token solutions use a smartphone to generate their tokens, and smartphones can be used to access CDE systems, this position essentially invalidates the majority of token or SMS-based two factor solutions.

Furthermore, while NIST SP 800-63r2 is an absolutely riveting read (I am sure the movie rights are being hotly negotiated as I write this blog), the concept of “independence” is not defined or discussed anywhere in the document.  The only mention of independence I could find is where the PCI standards discourages using biometrics for e-authentication (page 21).

The deeper I looked into this issue, the more misunderstandings and misstatements I uncovered.  For a mature technology, MFA still has many nuances.  Two of these nuances were hotly debated at the Community meeting.

Shared Credentials

The first issue was in regard to how credentials are protected.  One of the interpretations we heard during the Community meeting was that you cannot share credentials for both a login and access to a token.  For example, consider a web site that uses PKI authentication.  You use a Windows AD login and password to login into the site (something you know) and then a digital certificate as the second factor (something you have).  However, if that certificate is protected from access using the same Windows AD login and password, then there really is no independence between the factors.

Some people at the conference were extending this concept to apply to tokens on a smartphone.  If you use the same password for logging into host and for accessing the token app, then you still have essentially one-factor (the password) for access.

We disagree.

What these two examples are doing is conflating the actual something-you-know (login and password) with a protection mechanism around the something-you-have token.  If an attacker does not have the token app or certificate, then knowing the password remains irrelevant.  In other words, if the same password is used as a login, and protecting a token, it does not invalidate the token because an attacker would still have to obtain the token to execute an attack.  The two factors remain fundamentally independent, even if they happen to share the same password.  The sharing of a password is not a best practice, but it does not invalidate the MFA solution.

The NIST Special Publication (800-63r2) addresses this on page 21:

“While symmetric keys are generally stored in hardware or software that the Subscriber controls, passwords tend to be memorized by the Subscriber. As such, keys are something the Subscriber has, while passwords are something he or she knows.”

Another example of this interpretation is SSH keys.  Protected SSH sessions use not only a username and password (something you know) but also an SSH key, something you have.  It is up to the user to protect that key, much in the same way that users must protect their token apps or certificates.

These examples illustrate the importance of QSAs to understand not only the concepts behind a given technology, but also the details of a given instance.  If, for example, an attacker can use a compromised domain account to install an app and generate a token without requiring compromise of something else, such as stealing a phone or breaching a system where the token resides, then it is true that independence would be broken.  But it is impractical to extend this example to assume all instances of software “something you have” cannot be protected with the same shared secret as the “something you know.”

Shared Platforms

However, the drama really heated up when the issue of tokens on smartphones arose.  One of the speakers took a very strict position that you could not use the same for both access to CDE systems and to generate a token or OTP.  His contention was that this broke the independence requirement between factors.  They shared a platform.

This is impractical and essentially invalidates all smartphone-based tokens.  Furthermore, in our assessment, this does not break independence requirements.  Independence applies to the mechanism of authentication, not the platforms where those authentications take place.  If an attacker stole authentication credentials, they would still have to steal the actual smartphone running the token app.  The fact that the token app shares its password with the login is undesirable and reduces security slightly, however it does not fundamentally break the second authentication factor.  The token app remains something-you-have.

We agree that it is best practice is to use a different passwords for authentication credentials and accessing certificates or tokens.  However, merely accessing a site on the same device where a token is generated does not inherently break independence.

Conclusion

While the PCI Community meeting is always good for keeping up on the latest issues, we find that now more than ever, the PCI-DSS needs pragmatism.  The debates over MFA are interesting from an academic perspective, but offered little practical insight, other than the fact that folks are quite to argue a position without understanding the details.  MFA is still one of the best ways to shrink an attack surface area and increase security.

This debate also shows how PCI, like any complex standard, can quickly devolve into nitpicking debates over minutiae.  This is why hands-on technology experience is such an important skill for any PCI assessor.  Your auditor must have the ability to translate the intent of the standard into the operational realities of your environment.