PCI's breach-era authentication standards are complex, but necessary
With more than 80% of hack-driven breaches resulting from the use of default, stolen or weak passwords according to Verizon’s 2017 Data Breach Investigation Report, the payment card authority PCI Security Standards Council is updating industrywide standards to improve authentication, third party accountability and software design.
Among the most important of these is Requirement 8.3 of the Payment Card Industry Data Security Standard (PCI DSS 3.2), which goes into effect Feb. 1. Requirement 8.3 makes multifactor authentication (MFA) mandatory for all entities involved in payment card processing, including merchants, processors, acquirers, issuers and service providers, as well as anyone storing, processing or transmitting cardholder data or sensitive authentication data.
The changes come in response to major hacking incidents in the U.S., including the Target and Home Depot data breaches, and were in the works well before recent “mega-breaches” of compromised cardholder data. The 2013 Target breach alone compromised 40 million customers’ payment card information and partially exposed another 70 million.
The term multifactor authentication replaces the previously used term two-factor authentication, a seemingly subtle change, but an important one that codifies and clarifies minimum authentication requirements.
Another major change is the expansion of authentication requirements, which now impact all who have "non-console administrative access," to the Cardholder Data Environment (CDE). The MFA requirement now applies to everyone accessing data over a network rather than via a direct physical connection, including internal and external networks. It applies to general users, administrators and third parties such as vendors (for support and maintenance) with remote access to the network — wherever that access might ultimately result in access to the CDE. Think of this as the Target HVAC clause.
To help clarify where and how MFA should be implemented, the standards council has published “Information Supplement — Multi-Factor Authentication version 1.0,” which offers MFA implementation principles, reviews laws and regulations, and common authentication scenarios.
It’s well understood that implementing MFA requires the use of at least two of the three authentication factors: something you know (such as a password, PIN or answers to secret questions), something you have (such as a token device or smartcard), and something you are (such as biometrics).
The supplement also addresses the role of other factors: “Other types of information, such as geolocation and time, may be additionally included in the authentication process; however, at least two of the three factors identified above must always be used.”
This means, for example, that although supplemental factors such as geolocation and time data may be used to further reduce risk, MFA requirements still firmly apply.
The standard dictates that authentication mechanisms must be independent of each other. Access to one factor must not grant access to any other factor, and the compromise of one factor must not affect the integrity or confidentiality of any other factor. Some common scenarios to avoid:
Reuse of credentials: When a username/password combination is used to enter the company network, and the same credentials also grant access to an email account to which a one-time password is sent as second factor, these factors are not independent. The first factor (username/password) gives access to the email account and thus to the second factor.
Common access to certificates: A software certificate stored on a laptop (i.e., something you have) that is protected by the same set of credentials used to log in to the laptop (i.e., something you know) may not provide independence.
Single (mobile) device vulnerability: The council notes that “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.” When entering credentials via the same device that receives (or stores/generates) a second factor, a hacker who has control of the device might capture both authentication factors.”
The council advises that “where any authentication elements rely on a multipurpose consumer device, such as mobile phones and tablets, controls should also be in place to mitigate the risk of the device being compromised.”
Simply put, all factors in multifactor authentication are to be verified together in concert, prior to obtaining access to the system, so that a would-be fraudster can’t corrupt security from a stolen phone.