INFORMATION SUPPLEMENT Multi-Factor Authentication

6m ago
1.01 MB
12 Pages

INFORMATION SUPPLEMENTMulti-Factor AuthenticationVersion: 1.0Date: February 2017Author: PCI Security Standards Council

INFORMATION SUPPLEMENTGuidance for Multi-Factor AuthenticationTable of ContentsOverview .1MFA and PCI DSS .1Terminology .1Authentication Factors .2Independence of Authentication Mechanisms .2Out-of-Band Authentication .3Cryptographic Tokens .3Protection of Authentication Factors .5Multi-step vs. Multi-Factor .5Use of SMS for Authentication .6Laws and Regulations .6Common Authentication Scenarios .7Scenario 1 .7Scenario 2 .8Scenario 3 .9Scenario 4 . 10The intent of this document is to provide supplemental information.Information provided here does not replace or supersede requirements in any PCI SSC Standard.February 20171

INFORMATION SUPPLEMENTGuidance for Multi-Factor AuthenticationOverviewThe intent of multi-factor authentication (MFA) is to provide a higher degree of assurance of the identity of theindividual attempting to access a resource, such as physical location, computing device, network or adatabase. MFA creates a multi-layered mechanism that an unauthorized user would have to defeat in order togain access.This document describes the industry-accepted principles and best practices associated with multi-factorauthentication. The guidance in this document is intended for any organization evaluating, implementing, orupgrading a MFA solution, as well as providers of MFA solutions.MFA and PCI DSSPCI DSS requires MFA to be implemented as defined in Requirement 8.3 and its sub-requirements1.Guidance on the intent of these requirements is provided in the Guidance column of the standard, whichincludes; “Multi-factor authentication requires an individual to present a minimum of two separate forms ofauthentication (as described in Requirement 8.2), before access is granted.” The additional guidance in thisdocument does not extend the PCI DSS requirement beyond what is stated in the standard.While PCI DSS Requirement 8.3 does not currently require organizations to validate their MFAimplementation to all the principles described in this guidance document, these principles may beincorporated in a future revision of the standard. Organizations are therefore strongly encouraged to evaluateall new and current MFA implementations for conformance to these principles.TerminologyIn addition to terms defined in the PCI DSS Glossary of Terms, Abbreviations, and Acronyms, the followingacronyms are referenced:TermSE1DescriptionAcronym for Secure Element. Tamper-resistant hardware platform, capable of securelyhosting applications and storing confidential and cryptographic data.TEEAcronym for Trusted Execution Environment. Software that provides security featuressuch as isolated execution.TPMAcronym for Trusted Platform Module. Module that is dedicated and physically isolatedfrom the rest of the processing system microcontroller, which is designed to securehardware by integrating cryptographic keys into devices. It offers facilities for the securegeneration of cryptographic keys and limitation of their use.Refers to PCI DSS v3.2The intent of this document is to provide supplemental information.Information provided here does not replace or supersede requirements in any PCI SSC Standard.February 20171

INFORMATION SUPPLEMENTGuidance for Multi-Factor AuthenticationAuthentication FactorsThe overall authentication process for MFA requires at least two of the three authentication methodsdescribed in PCI DSS Requirement 8.2:a) Something you know, such as a password or passphrase. This method involves verification ofinformation that a user provides, such as a password/passphrase, PIN, or the answers to secretquestions (challenge-response).b) Something you have, such as a token device or smartcard. This method involves verification of aspecific item a user has in their possession, such as a physical or logical security token, a one-timepassword (OTP) token, a key fob, an employee access card, or a phone’s SIM card. For mobileauthentication, a smartphone often provides the possession factor in conjunction with an OTP app ora cryptographic material (i.e., certificate or a key) residing on the device.c) Something you are, such as a biometric. This method involves verification of characteristics inherentto the individual, such as via retina scans, iris scans, fingerprint scans, finger vein scans, facialrecognition, voice recognition, hand geometry, and even earlobe geometry.Other types of information, such as geolocation and time, may be additionally included in the authenticationprocess; however, at least two of the three factors identified above must always be used. For example,geolocation and time data may be used to restrict remote access to an entity’s network in accordance with anindividual’s work schedule. While the use of these additional criteria may further reduce the risk of accounthijacking or malicious activity, the remote access method must still require authentication via at least two ofthe following factors: something you know, something you have, and something you are.Independence of Authentication MechanismsThe authentication mechanisms used for MFA should be independent of one another such that access to onefactor does not grant access to any other factor, and the compromise of any one factor does not affect theintegrity or confidentiality of any other factor. For example, if the same set of credentials (e.g.,username/password) is used as an authentication factor and also for gaining access to an e-mail accountwhere a secondary factor (e.g., one-time password) is sent, these factors are not independent. Similarly, asoftware certificate stored on a laptop (something you have) that is protected by the same set of credentialsused to log in to the laptop (something you know) may not provide independence.The intent of this document is to provide supplemental information.Information provided here does not replace or supersede requirements in any PCI SSC Standard.February 20172

INFORMATION SUPPLEMENTGuidance for Multi-Factor AuthenticationThe issue with authentication credentials embedded into the device is a potential loss of independencebetween factors—i.e., physical possession of the device can grant access to a secret (something you know)as well as a token (something you have) such as the device itself, or a certificate or software token stored orgenerated on the device. As such, independence of authentication factors is often accomplished throughphysical separation of the factors; however, highly robust and isolated execution environments (such as aTrusted Execution Environment [TEE], Secure Element [SE], and Trusted Platform Module [TPM]) may alsobe able to meet the independence requirements.Out-of-Band AuthenticationOut-of-band (OOB) refers to authentication processes where authentication methods are conveyed throughdifferent networks or channels.Where authentication factors are conveyed through a single device/channel—for example, enteringcredentials via a device that also receives, stores, or generates a software token—a malicious user who hasestablished control of the device has the ability to capture both authentication factors.Transmission of a one-time password (OTP) to a smartphone has traditionally been considered an effectiveout-of-band method. However, if the same phone is then used to submit the OTP—for example, via a webbrowser—the effectiveness of the OTP as a secondary factor is effectively nullified.Out-of-band conveyance of authentication mechanisms is an additional control that can enhance the level ofassurance for multi-factor authentication. In lieu of the ability to use out-of-band communication, theauthentication process should establish controls to guarantee that the individual attempting to use theauthentication is, in fact, the legitimate user in possession of the authentication factor.Cryptographic TokensCryptographic tokens may be embedded into a device or stored on separate, removable media. The followingguidance is based on NIST SP800-1642 and NIST SP800-1573, and considers some common form factorsthat are often used with mobile computing devices.23NIST Special Publication 800-164 (Draft), Guidelines on Hardware-Rooted Security in Mobile Devices (Draft). 64/sp800 164 draft.pdf (accessed: November 07, 2016).NIST Special Publication 800-157 Guidelines for Derived PIV Credentials. ations/NIST.SP.800-157.pdf (accessed: November 07, 2016)The intent of this document is to provide supplemental information.Information provided here does not replace or supersede requirements in any PCI SSC Standard.February 20173

INFORMATION SUPPLEMENTGuidance for Multi-Factor AuthenticationRemovable (Non-Embedded) Hardware Cryptographic TokensIn this category of devices, a private key resides in a hardware cryptographic module (or physicalsecurity token) that is physically separate from the mobile computing device. Access to either themobile computing device or cryptogram stored on the token does not grant access to the other, thusmaintaining the independence of authentication factors.Each of the form factors described below supports a secure element (SE), a tamper-resistantcryptographic component that provides security and confidentiality in mobile devices. SD Card with Cryptographic Module – A non-volatile memory card format for use in portabledevices such as mobile phones and tablet computers. Removable UICC with Cryptographic Module – The Universal Integrated Circuit Card (UICC)configuration is based on the GlobalPlatform Card Specification v2.2.1 [GP-SPEC] andprovides storage and processing, as well as input/output capabilities. USB Token with Cryptographic Module – A Universal Serial Bus (USB) token is a device thatplugs into the USB port on various IT computing platforms, including mobile devices andpersonal computers. USB tokens typically include onboard storage and may also includecryptographic processing capabilities—e.g., cryptographic mechanisms to verify the identity ofusers. USB token implementations that contain an integrated secure element (an integratedcircuit card or ICC) are suitable for use in the authentication process.Embedded Cryptographic TokensAn authentication credential and its associated private key may be used in cryptographic modulesthat are embedded within mobile devices4. These modules may either be in the form of a hardwarecryptographic module that is a component of the mobile device or in the form of a softwarecryptographic module that runs on the device.Hardware cryptographic modules are preferred over software due to their immutability, smaller attacksurfaces, and more reliable behavior; as such, they can provide a higher degree of assurance thatthey can be relied upon to perform their trusted function or functions.Protecting and using the authentication credential and the corresponding private key in software maypotentially increase the risk that the key could be stolen or compromised.4Draft NIST Interagency Report 7981, Mobile, PIV, and Authentication. URL: 1/nistir7981 draft.pdf (accessed: November 07, 2016)The intent of this document is to provide supplemental information.Information provided here does not replace or supersede requirements in any PCI SSC Standard.February 20174

INFORMATION SUPPLEMENTGuidance for Multi-Factor AuthenticationProtection of Authentication FactorsTo prevent misuse, the integrity of the authentication mechanisms and confidentiality of the authenticationdata need to be protected. The controls defined in PCI DSS Requirement 8 provide assurance thatauthentication data is protected from u