Late this week the PCI Security Standards Council issued a new information supplement titled ‘Multi-Factor Authentication’ after the brew-ha-ha that occurred last fall at the Community Meeting in Las Vegas. For once, the Council has issued an excellent reference regarding the issues of multi-factor authentication (MFA). Although I still have a couple of minor bones to pick about this document, but more on that later.
If you understand the concepts of MFA, you can skip through the document to the end where the Council presents four scenarios on good and bad MFA. These are well documented and explain the thought process behind why the scenario works or does not work for MFA. The key takeaway of all of this is the independence of the MFA solution from the logon process. The Council is getting in front of the curve here and stopping people from creating insecure situations where they believe they are using MFA that minimizes or stops breaches through administrators or users with access to bulk card data.
Now for a few things that I do not necessarily agree with in this document.
The first involves the Council’s continued belief that hardware security modules (HSM) are actually only hardware. On page four, the following statement is made.
“Hardware cryptographic modules are preferred over software due to their immutability, smaller attack surfaces, and more reliable behavior; as such, they can provide a higher degree of assurance that they can be relied upon to perform their trusted function or functions.”
The Council has made similar statements over the years in the mistaken assumption that HSMs are only hardware. HSMs are hardware that use software to manage keys. There are standards that are followed (e.g., FIPS 140) to ensure that the HSM remains secure, but these devices are predominately software driven. That is not to say that just any device can serve as an HSM, but a lot of us in the security community are concerned that the Council continues to perpetuate a myth that HSMs are only hardware which is patently false.
My other issue comes on page six as part of the discussion regarding the use of SMS for MFA.
“PCI DSS relies on industry standards—such as NIST, ISO, and ANSI—that cover all industries, not just the payments industry. While NIST currently permits the use of SMS, they have advised that out-of-band authentication using SMS or voice has been deprecated and may be removed from future releases of their publication.”
While everything in this statement is accurate, it gives the uninitiated the impression that SMS or voice is no longer a valid MFA solution. I know this to be true because I have fielded some questions from clients and prospects on this subject, particularly about SMS. The key is that this is not SSL and early TLS where NIST called them out as insecure and to no longer be used. This is a “heads up” from NIST to everyone that there is an issue that makes SMS and voice not secure enough for MFA.
But while there is a risk, a lot of us in the security community question the viability of that risk when matched against merchant risk versus a bank or a government agency. While I would not want any bank or government agency to use SMS or voice for MFA, a small business may not have a choice given their solution. The reason is that the risk of an attack on SMS or voice is such that only a high-value target such as a bank or government agency would be worth such an effort. In my very humble opinion, while a total ban is the easy solution, this is an instance where the Council should take a more nuanced approach toward the use of SMS and voice for MFA. The bottom line to me is that small merchants using any MFA solution, even if flawed, is better than using no MFA solution.
I would recommend the following approach to manage this risk.
- Level 4 merchants can be allowed to use SMS or voice for MFA.
- Level 1, 2 and 3 merchants would be allowed to transition away from SMS and voice to a more secure MFA solution within one year of NIST stating that they are no longer acceptable.
- All service providers would not be allowed to use SMS or voice for MFA once NIST states that both are no longer acceptable. This means service providers should start transitioning now if they use either.
Those are my thoughts on the subject. I look forward to the comments I am sure to receive.
PCI Guru 
OK, understood. I use both RSA SecurID and Symantec VIP and neither will actually submit the token for me to the waiting login screen on my laptop. I have to manually type the token into the laptop just as I did for my SecurID hard token. But that vendor I mentioned somehow transmits the token from the smartphone to the actual application with a push of the button and logs me in without having to type anything in the laptop.
As long as that process does not occur on the same device that is logging into the application/network, then you meet the requirement as defined by the Council in their latest MFA guidance.
This is the note that got my attention: “Transmission of a one-time password (OTP) to a smartphone has traditionally been considered an effective out-of-band method. However, if the same phone is then used to submit the OTP—for example, via a web browser—the effectiveness of the OTP as a secondary factor is effectively nullified.”
A very large security vendor showed us the commercial product they use for two-factor login. They use a real computer for credentials and then a token is sent to a phone. They click the button on the phone app and all of a sudden the laptop progresses to being in the app. That note seems aimed squarely at that and similar products.
Symantec VIP and RSA SecurID soft-token work that way. It is acceptable to use the smartphone as the token, you just cannot also logon on from that device. The Council wants to OOB token device and the device connecting to be separate.
This sounds the same as what the banks themselves have been doing since the early 00s, i.e. you try to reset your password and are given a code, a robot voice phones you and you tell the robot the code, and then the website automatically updates itself.
One thing to note about how the banks do it is that the login and token are in bounds but the token can only be submitted OOB. This is different to the more recent SMS solutions where you receive the token OOB but the submission is in bounds.
The council’s wording seems to be written to cover both solutions which creates some confusion.
Agreed. But the key is that either way, the process required separate devices.