PINs, Passwords, and PCI

What is the difference between Passwords and Passphrases, PINs, and other authentication factors under PCI DSS? Our team was recently asked for a second opinion on a scenario that seemed like a simple question. When we dug into it, we found some useful but scattered guidance in PCI DSS and its supporting documents . While ambiguity can support flexibility, it can also lead entities astray. PCI's flexibility can sometimes be akin to running with scissors. And this question is no exception.

Can a PIN combined with a Second Authentication Factor Meet Compliance for MFA?

The question was - Can a PIN combined with a second authentication factor meet compliance for MFA? The external opinion was concerned that the PIN was not complex enough to support two-factor authentication when combined with a second authentication factor – in this case an RSA Secure ID token code. Further, they were asking the entity to add a password to the authentication to enable it to meet normal password complexity requirements. After a careful review of the available guidance (see details below), we concluded that:

• A PIN is a string of numerical digits, according to the NIST standards referenced by the PCI DSS.
• There are password/passphrase composition requirements in the PCI DSS.
• There are no PIN composition requirements in PCI DSS (e.g. length/strength).
• The PCI DSS, and supporting guidance, clearly differentiate PIN’s and passwords/passphrases. Specifically, there is no guidance that equates a PIN = password/passphrase.
• A PIN alone can be used as a “something you know” authentication factor. However, the PIN must be protected from brute-force/guessing attacks per additional guidance (see Details & Learn More below).

Putting this together, a PIN is not the same as a password used for normal network authentication and reserved purely for this elevated MFA access in the scenario presented to us. There is no opportunity to “steal” or harvest this PIN unless the employee writes it down. This fact makes a PIN a strong “something you know” and significantly less susceptible to brute force attacks, cracking, dark-web compromised, credential stuffing, etc., and all the reasons why the DSS has extra requirements (e.g. length, strength, expiry) for passwords/passphrases.

Having said all of the above, it is also not unreasonable to expect stronger (longer) PINs in products and solutions.

PCI Details on Authentication Factors and Steps

Resolving questions like this under PCI requires looking at the authoritative documents, including the standard itself, and additional guidance such as Information Supplements and general FAQ's. Guidance is intended to provide clarification but should not be taken as overriding or superseding the authoritative documents.

• Requirement 8.2 requires that to authenticate a user there needs to be a unique user identifier in combination with another method

  • Something you know, such as a password or passphrase.
  • Something you have, such as a token device or smart card.
  • Something you are, such as a biometric.
• Requirement 8.2.3 through 8.2.6 specifically apply criteria to passwords/passphrases. These are the familiar complexity rules, length, and change frequency controls.
• Requirement 8.3 speaks to the use of multi-factor authentication and refers to the factors (authentication methods) from 8.2.
• The DSS glossary defines Multi-Factor Authentication as “Method of authenticating a user whereby at least two factors are verified. These factors include something the user has (such as a smart card or dongle), something the user knows (such as a password, passphrase, or PIN) or something the user is or does (such as fingerprints, other forms of biometrics, etc.)”
• The FAQ's #1426 & 1449 make it clear that two-step authentication is not the same as two-factor/multi-factor authentication and spells out the conditions where two-step can be used

• The MFA Information Supplement:

  • Expands on the "Something you know, such as”, adding PINs and the answers to secret (challenge-response) questions.
  • Speaks to the protection of authentication factors, specifically that "Passwords and other “something you know” data should be difficult to guess or brute-force and be protected from disclosure to unauthorized parties".
  • Explains the need for the authentication mechanisms to be robust and independent such that a compromise of one does not lead to a compromise of another. It doesn't explicitly say that independent two-step authentication is acceptable (see FAQ#1449).
• Other references, such as NIST, tended to define PINs simply as authenticator comprised of digits without talking about security properties. We didn't find this definition to be very useful. For example, Windows Hello PINs can be configured for length and to allow letters as well as numbers.
• NIST does provide a document discussing threats to different types of authenticators and making recommendations.

Two Additional Questions

As often happens, investigating PCI guidance can lead to additional debates and questions. In this case two questions came up:

• Was the omission of prescriptive requirements for protection of PINs and Secret Questions in the DSS intentional or an oversight? It may be that the PCI SSC intended for a PIN to be applicable to the same requirements as a password, however they did not define this in any guidance.
• What's to stop someone arguing their numeric passwords are just PINs and all of the password requirements just don't apply to them and you must pass them because there are no prescriptive requirements for PINs (nor security questions) in the DSS?

The short answers to these questions are that there is ample guidance within PCI and NIST covering other forms of “something you know” factors, and that entities should avoid wordsmithing and interpreting the DSS in ways that are clearly “running with scissors”.

Learn More

• Authoritative PCI DSS Documents:

  • PCI DSS v3.2.1 Standard with official guidance https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf
  • Detailed reporting instructions https://www.pcisecuritystandards.org/documents/PCI-DSS-v3_2_1-ROC-Reporting-Template.pdf
  • There is no Technical (mandatory) FAQ document published for PCI DSS
  • PCI Glossary https://www.pcisecuritystandards.org/documents/PCI_DSS_Glossary_v3-2.pdf

• Additional guidance:

  • (2017) Multi-factor Authentication Information Supplement with Scenarios https://www.pcisecuritystandards.org/pdfs/Multi-Factor-Authentication-Guidance-v1.pdf
  • FAQ#1426 (2017) Explains why two-factor and two-step authentication are different and why two-step authentication may not meet MFA requirements https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/Is-two-step-authentication-the-same-as-two-factor-or-multi-factor-authentication
  • FAQ#1449 (2018) Explains how some two-step authentication can be acceptable for MFA https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/Is-two-step-authentication-acceptable-for-PCI-DSS-Requirement-8-3
  • FAQ#1425 (2016) https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/What-is-the-difference-between-multi-factor-authentication-and-two-factor-authentication
  • FAQ#1078 (2020) https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/In-what-circumstances-is-multi-factor-authentication-required

• Other References:

  • NIST 800-63 Digital Identity Guidelines https://csrc.nist.gov/publications/detail/sp/800-63/3/final
  • NIST PIN Definition and references https://csrc.nist.gov/glossary/term/personal_identification_number

• Articles:

  • Time to Kill Security Questions—or Answer Them With Lies https://www.wired.com/2016/09/time-kill-security-questions-answer-lies/
  • Pwned security questions https://haveibeenpwned.com/PwnedWebsites include Ashley Madison, gPotato, Health Now Networks, Neteller, vBulletin, VTech,
  • The Yahoo breach included some unencrypted security questions https://www.theverge.com/2017/10/3/16414306/yahoo-security-data-breach-3-billion-verizon