Archive for December 20th, 2016


An Update On Multi-Factor Authentication

In the November 2016 Assessor Newsletter there is an update to the Council’s statements at the 2016 Community Meeting’s QSA Forum discussion regarding multi-factor authentication (MFA).

“We had a moment of excitement at the North America Community Meeting in September when we responded to a question in the Assessor Session about MFA. As several of us from the Council pointed out, some techniques historically in use are falling out of favor as acceptable approaches to MFA because, as they are becoming used, they fail to meet the basic requirements of MFA. A recent NIST announcement associated with a proposed revision to NIST Special Publication 800-63 series raised the potential of a sunset date for use of SMS as an out-of-band mechanism for a factor in MFA. Based on the questions asked, we felt a refresher on MFA would be of value.

Assessors should understand that multifactor authentication requires two or more independent factors used in such a way that the presenter of the factors gains no knowledge of whether any factor is valid until all factors have been presented. For example, if the first factor is submitted and results in an indication to the user that it is valid before the second factor is requested, then what you actually have is two, single-factor authentications. The critical issue is not when the validation is actually done; rather it is when feedback to the user is provided. If the user can’t tell which factor failed to grant access, then you have MFA. This common practice is illustrated in Figure 1. Figure 2 illustrates the better practice.


Figure 1 is sometimes referred to as a multistep authentication. Figure 2 unifies authentication into a single step. By doing the validation of both factors before providing an indication of authorization success or failure, no information is leaked about either factor.

MFA also requires that the factors be different in type. That is, at least two of the usual three types given below are required:

  • Something you know (e.g., password, PIN, security question challenge)
  • Something you possess (e.g., ICC card, physical token, cryptographic token or private key)
  • Something you are (e.g., physical biometric or behavioral biometric)

The factors must also be independent. Access to one should not grant access to the other. For example, if I use my mobile phone as my device for logging into a system and the system can validate my device with a high-degree of assurance, then it might be the something I possess. However, if it is also where I store my password (or the device to which a one-time-password (OTP) or password reset would be sent), then possession of the device may grant access to both factors. NIST acknowledges this as a risk in its DRAFT NIST Special Publication 800-63B Digital Authentication Guideline: Authentication and Lifecycle Management (5.1.3. Out-of-Band Devices).

Other circumstances may also result in loss of independence, for example, relying on a digital certificate as one factor if it is on the same device into which you are entering your password. If compromise of the device equates to having both the digital certificate and your password, then independence is lost. A similar issue exists when one factor gives access to more than one of the factors used in MFA. This is common with mobile devices that use a single factor to unlock (whether it be a passcode or a biometric) that then gains you access to other authenticators, e.g., stored passwords, the device’s identity, private keys, or software tokens. The assessor should carefully examine any method alleged to be multifactor to verify that it meets all of the requirements. For more information on this subject, consider the following publications:

  • DRAFT NIST Special Publication 800-63-3 Digital Authentication Guideline
  • DRAFT NIST Special Publication 800-63B Digital Authentication Guideline: Authentication and Lifecycle Management
  • DRAFT NIST Special Publication 800-63C Digital Authentication Guideline: Federation and Assertions
  • ISO 19092:2008 Financial Services Biometrics Security Framework
  • ISO/IEC 27040:2015 Information technology — Security techniques — Storage security

[1] Per our current PCI DSS FAQ, multistep authentication may also qualify as multifactor, as long as at least two types of factors are used and the first step is not sufficient to gain knowledge of (or constructive use of) the second authentication factor. Note that an updated version of this FAQ will be published shortly.”

So let us discuss what we probably agree with the Council on in their statements above because that is the easier discussion.

I think most security professionals would agree with the discussion that the factors must be independent of the device being used to log onto the systems.  As a result, if you have the RSA SecurID Software Token or Symantec VIP apps on a cell phone or tablet, that device should also not be able to log onto the systems you are trying to protect.  The same holds true with the practice of putting a certificate on a device for MFA.  The rationale being that if an attacker has the device and the device owner’s credentials, MFA is doing nothing because the second factor will either already be on the device or will be displayed there.

However, the “moment of excitement” occurred because that was not the discussion that occurred at the QSA session.  What was stated at that session was that ALL out-of-band MFA to anything other than a traditional fob was no longer allowed.  I know that was what I heard and I was not the only one that interpreted the statements made that way.  So it was not like I was the only one that heard something wrong as there were a lot of people in that ballroom that heard the exact same thing.  That is what we all heard and why there was a “moment of excitement”.  And rightly so, as that would have put about 90% of MFA solutions as totally non-compliant.

There has been a lot of back channel discussion between QSAs regarding the Community Meeting MFA discussion.  One of the first discussions was about the risk involved.  While we mostly agree with the Council’s position on the independence issue, we have concerns about full adoption of all of NIST’s recommendations regarding MFA.  The Council has acted like SMS and Voice MFA was killed by NIST but that is not the case.  What NIST is saying is:

“Note: Out-of-band authentication using the PSTN (SMS or voice) is deprecated, and is being considered for removal in future editions of this guideline.”

Deprecated means that it is not recommended, but is still allowed.  Why?

Because there is a risk of SMS being intercepted, but to do that is not necessarily an easy task as say a man-in-the-middle attack of Wi-Fi.  During the back channel discussions, it was questioned whether or not the Council truly realizes the real world risk of intercepting SMS and how that plays against a government entity or a bank versus your run of the mill organization.  It is not a risk that has a “one size fits all” rating because of the complexity of the task.  And that is what has the security community up in arms about is that NIST’s recommendation is probably a good thing for the government or a bank to follow, but might still be acceptable for small business versus no MFA or even worse, lying to their bank that they have MFA.

Keep in mind that this is interception, so the target will not receive the message, only the attacker will receive it.  If you want to pass something else along, that further adds to the complexity.  In order to intercept SMS, one has to accomplish one of the following.

  • Infect the target’s smartphone with a virus.
  • Reissue the target’s SIM.
  • Hack the PSTN.
  • Intercept the target’s cell service via a Stingray type of device.

It is relatively easy to infect smartphones on a large scale.  However it is very hard to infect a particular smartphone or group of smartphones without the attacker physically getting their hands on the phone(s).  Given the prevalence of using fingerprints and patterns to log onto phones, even physically having the phone makes infecting it not a quick task and requires equipment to break in and infect the device.  Doing that without the target(s) being suspicious is probably very low.

Reissuing a target’s SIM is relatively easy but creates a huge timing issue.  Because it works only once, that means the attacker must reissue the SIM right at the time the target is receiving the SMS MFA or they will miss the code.  The risk of that timing happening is very, very low even for employees of government entities.

So this leaves us with hacking the PSTN and using a Stingray device.  Hacking the PSTN is also supposedly relatively easy.  Here are the steps required to intercept SMS.

  • The attacker must create their own fake call processing capability (MSC).
  • The attacker must then get the real MSC to release the target’s phone to the fake MSC.
  • The attacker must then point his fake MSC to their own device for the SMS MFA message.
  • The attacker must then wait for the target to logon to generate an SMS MFA request.
  • The attacker must then use the SMS MFA before the target generates a new SMS MFA because they did not receive the original SMS MFA.

The first problem is creating a fake MSC.  This is not as easy as you might think for your run of the mill attacker.  Governments have them, criminal organizations have them, but your average hacker going after credit cards is not going to have such capability unless they are extremely serious about their craft as there are much easier ways to go after cardholder data (CHD).

But assuming we have someone that is truly determined and has such a capability, they must then intercept the SMS MFA message and use it before the target gets wise that their SMS is being intercepted.  This means the attacker has to hope that their target is not a heavy user of SMS.  Portio Research estimates that there are around 16 million SMS messages sent every minute in the world.  Given there are approximately 6.8 billion phones in the world, that means that your target will, on average, receive just over three messages in a day via SMS.  One of those likely to be the MFA message you are trying to intercept probably the first message of the day.  So predictability is on the side of the attacker.

That said, most users of SMS MFA are going to likely only try twice to get their SMS MFA message before they call the help desk to find out what the problem is with the MFA solution.  It will likely be at that point that any attacker will likely be found out because the help desk will discover that the user complaining is already logged onto the systems.  So just because the attacker has access does not necessarily mean they are home free and can do as they please.

As a result, hacking SMS through the PSTN, while possible, is probably only a risk at a very high value target will likely have to face.

So in this discussion of SMS MFA risk, what we have left is using a Stingray device to intercept the target’s mobile service.  This will be like drinking water through a firehose because you will not only have to grab your target’s service, but everyone else that is nearby your Stingray device.  Which brings up the next issue which is that your Stingray device will have to stay in near proximity to your target in order to grab the information you desire.  If you target is truly mobile, that could be very problematic unless you have the resources to install Stingray devices like the FBI or CIA on every cell tower in town.  Again, I would say the likelihood of such an attack is relatively low for all but the most determined attackers which will stop at nothing to get into an organization.

At the end of this mental exercise, we again question the Council adopting NIST’s recommendation regarding SMS MFA without considering the actual real world risk.  Just because a threat exists, does mean the risk is automatically high because NIST is getting ready to deprecate it.  Again, NIST is securing the government and is sharing the results of their research with the rest of us because we, as taxpayers, have paid for it and deserve the results of their research.  That said, that does not mean that everything they produce is always relevant to every organization outside of the government.  Most of it is, but not everything.  This SMS MFA deprecation is probably relevant at some point, but for the current timeframe, SMS MFA is better than no MFA.

But that brings us to the fact that NIST did not say that SMS MFA cannot be used as they did with SSL and Early TLS.  All NIST did say was that they do not recommend it and that sometime in the future they may not allow it.  As a result, if an organization is using SMS MFA, it is still allowed to be used.  NIST has only put organizations on notice that at some point, SMS MFA will no longer be allowed.

But by their statements, the Council has taken NIST’s future deprecation comment to mean that SMS MFA is dead now and that is false.  Yes, organizations should probably look at any SMS MFA solution skeptically from here on out, but SMS MFA is still allowed by NIST just not recommended because of the risk.  That said and as has been discussed, we question if the risk presented is realistic for all organizations given the effort required.

So let us bring this back to the real world.  The vast majority of large retailers have or are in the process of implementing P2PE/E2EE solutions with tokenization.  Those implementations that are in process will likely be done by the end of 2017.  Those remaining 98% of the rest of retailers will likely never ever encounter it because of the effort required to tap SMS just does not justify the reward.

There is a tremendous MFA infrastructure installation and the Council by their statements threatened the vast majority of that install base with their statements that did not match what NIST was stating.  That is what we are arguing over and what drew the “moment of excitement” at the Community Meeting.

In the end, while it is good to know that NIST believes SMS MFA to be a bad solution going forward, exactly what is the Council protecting with their statements?  With CHD no longer stored by large retailers, the risk is at the small retailers, transaction gateways, transaction processors and banks.  So the Council’s and NIST’s recommendations should be focused at those entities that actually pose a risk and not painted with a broad brush against all organizations.

The Council has chastised us all over the years for not focusing on the risk presented in our assessments.  It is time for the Council to take some of that same medicine and recognize that not every NIST pronouncement needs to be tossed out to the PCI community as though it is gold.  The Council also needs to recognize the risk presented and act accordingly.  It is no longer 2008 and organizations are not protecting SAD/CHD.

A lot has changed in the decade since the Council was founded.


If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.


December 2016
« Nov   Jan »

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,775 other followers