Navigating New PCI DSS 3.2 Guidelines for MFA With Duo
When you’re trying to parlay a multi-factor authentication (MFA) product into a solution that complies with current requirements and stays ahead of future ones, it’s hard to tell which way the ship is sailing — especially when you run up against parts that are more what you’d call guidelines than actual rules. PCI DSS 3.2 went into effect in October 2016, with requirement 8.3.1 (expanded use of MFA) coming into effect on February 1, 2018. In the meantime, the PCI Council has come out with an MFA Supplement that sets forth some guidelines that may possibly be incorporated into the standard at some point in the future.
Now, Duo helps meet these guidelines, with features such as:
- Policies to prevent authentication login from specific locations, networks or IP addresses
- Strong authentication with Security Element (SE) or U2F
- An easy to use out-of-band authentication factor (Duo Push, based on asymmetric keys)
Your Compass: Complete Authentication Visibility
However, there’s one guideline in the supplement that we know from experience is likely to create problems for both the user and the support staff: “no prior knowledge of the success or failure of any factor should be provided to the individual until all factors have been presented.”
Remember that PCI requirements — and indeed, the whole standard — are designed to mitigate risk scenarios around credit card theft. In this case, one of the security threats PCI is addressing is an attacker trying to guess (or brute force) an account’s username and password. It’s a common tactic, and many security assessors and penetration testers disapprove of the notion of letting anyone know what they got wrong in a login sequence, just in case it’s an attacker.
But anyone who has had to staff a help desk knows how frustrating it is for the user, who may not even be sure of the username, much less the password. The conventional assumption that a user always knows and remembers their username dates back to a time in which everyone only had one or two accounts, usually just for work.
Today, by virtue of being business partners, reporting entities, and online consumers, people have literally hundreds of accounts, many of them predating password managers by a decade. Some of these accounts may not be used more than once a year, if that often. It’s completely normal for them to struggle with remembering usernames and passwords, particularly when those usernames were assigned in an enterprise context.
The practice of concealing details on which part of an authentication process failed is more commonly known in the industry as “security by obscurity.” And in this case, it’s not necessary, since there are other measures you can take to mitigate the risk of password guessing or brute forcing attempts. Most systems today enforce a lockout (either temporary or permanent) after a certain number of incorrect attempts; giving more feedback will help the user figure out what they’re doing wrong and help them stay within that limit.
Some retailers, who deal with account takeover (ATO) attacks on a regular basis, block attempts from known malicious addresses before they can even start rattling the doorknobs. Even if an attacker manages to use the right username and password, Duo’s push notification gives the details of the secondary request, allowing the original user to indicate that the request is fraudulent and deny it.
Don’t Conflate ‘Feedback’ With ‘Bypass’
The next part of this PCI guideline reads: “If an unauthorized user can deduce the validity of any individual authentication factor, the overall authentication process becomes a collection of subsequent, single-factor authentication steps, even if a different factor is used for each step.”
We don’t agree with this arbitrary division of a multi-factor authentication process into “steps” just because the user receives feedback on the primary authentication success or failure. That’s independent of the other possible risk: that the MFA process could be interrupted and the user could bypass the next factor in the sequence. Giving feedback and being bypassed are two different issues, and shouldn’t be conflated in the one guideline.
Usable, Strong and Informed Security
At Duo, we believe in providing strong security with usability. We provide several robust measures to mitigate brute-force attempts, in addition to other security risks, such as man-in-the-middle attacks, phishing and more. Duo provides IT admins with detailed reports for logging and auditing purposes of all authentication attempts, as well as APIs to export that data into a SIEM or other system to monitor anomalous activity (see, for example, our Splunk Connector).
The bottom line is that enterprises have to make tradeoffs every day between security and usability. They should be able to compare their own support costs of troubleshooting an MFA sequence, and in some cases potentially losing customers, against a risk scenario that they may already be able to mitigate with other controls.
What can organizations do to address these guidelines going forward?
- As always, get your QSA’s (Qualified Security Assessor) view of the issues. Look at all your MFA process flows, particularly where you’re rolling out the technology for the first time. Your application security testing (such as for Requirement 6.5.8) should include checks to ensure that a successful primary authentication doesn’t allow the user to pivot and gain access before the secondary authentication takes place.
- Make sure you have mitigating controls on your primary authentication to thwart password guessing and brute-force attempts, such as limits on the number of attempts within a short period of time. (Some account takeover attacks now spread out their attempts over days and different IP addresses, so monitoring is critical.)
- If you have help desk statistics on calls from users who are having trouble authenticating, use those to estimate the overall support cost today, and how it might change if you had to remove or change feedback messages.
- If you’re in a position to give feedback to the PCI Council, share your opinion!
For more guidance, check out A Guide to Stronger Security in PCI DSS 3.2.