Frequently Asked Question
What is the Council's guidance on the use of SHA-1?
A number of industry standards bodies have transitioned away from allowing the use of SHA-1 in certain circumstances. For instance, as of December 31, 2013 the National Institute of Standards and Technology (NIST) has prohibited the use of SHA-1 for digital signatures. Likewise, members of the Certification Authority Browser Forum (CA/Browser Forum) have ceased issuing new SHA-1 certificates and will no longer trust code signed with a SHA-1 based digital signatures (effectively prohibiting the use of SHA-1 for code signing) after January 1, 2017. After this date, entities that have not upgraded their SSL/TLS certificates signed with SHA-1 based digital signatures could experience certificate errors, which could impact communications. For example: connections between browsers and websites, or connections to/from ATMs and payment terminals where digital certificates are used for authentication with a payment gateway. Merchants are encouraged to contact their service providers, acquirers, and/or terminal vendors, as applicable, to update their payment terminals and websites.
For other use cases, such as password hashing, SHA-1 is currently permitted by NIST. Regardless of the specific use case, SHA-1 is an aging and increasingly vulnerable hashing algorithm. As is the case with any aging technology, entities should have plans in place to replace insecure cryptographic hash functions with more secure options such as the SHA-2 and SHA-3 family of algorithms.
The continued use of SHA-1 as a security control has the following considerations for PCI standards:
- PCI DSS and PA-DSS require the use of "strong cryptography" for a number of control areas. Whether the use of SHA-1 meets the intent of "strong cryptography" will depend on how SHA-1 is used. The Council defers to industry standards bodies such as NIST and ANSI for determining the acceptability of specific cryptographic functions. Organizations should refer to industry resources such as NIST Special Publication 800-131A and other industry guidance for additional information on acceptable uses for SHA-1.
- The presence of SHA-1 in certain use cases may result in an ASV scan failure. Organizations utilizing SHA-1 for digital signatures associated with browser communications should replace expired or vulnerable certificates as soon as possible, or risk failing quarterly ASV scans beginning January 1, 2017. Entities that have not completely migrated away from SHA-1 will need to follow process outlined in the ASV Program Guide section "Managing False Positives and Other Disputes" to document how the risk has been addressed, for example to confirm the affected system is not susceptible to the particular vulnerabilities.
- As of the release of version 3, the PCI PTS POI standard does not permit the use of SHA-1 for digital signatures on PTS POI devices. This includes certificates used by the device that are non-device-specific and part of a vendor PKI, up to and including a vendor root certificate. The continued use of SHA-1 is permitted in only in the following scenarios:
- Within top-level certificates (the Root Certificate Authority), which is the trust anchor for the hierarchy of certificates used.
- Authentication of initial code on ROM that initiates upon device startup (note: all subsequent code must be authenticated using SHA-2)
- In conjunction with the generation of HMAC values and surrogate PANs (with salt), for deriving keys using key derivation functions (i.e., KDFs) and random number generation.
Related
-
When should an entity implement PCI DSS requirements noted as best practices until a future date?
-
For PCI DSS, can multi-factor authentication (MFA) implementations indicate the success of a factor prior to presentation of subsequent factors?
-
What is the completion date for PCI DSS assessments documented in a Report on Compliance and its related Attestations of Compliance?
Featured FAQ Articles
Featured
-
Do PCI DSS requirements for keyed cryptographic hashing apply to previously hashed PANs?
-
Is the PCI DSS Attestation of Compliance intended to be shared?
-
How does an entity report the results of a PCI DSS assessment for new requirements that are noted in PCI DSS as best practices until a future date?
-
Where do I direct questions about complying with PCI standards?
-
Can SAQ eligibility criteria be used for determining applicability of PCI DSS requirements for assessments documented in a Report on Compliance?
Most Popular
-
When should an entity implement PCI DSS requirements noted as best practices until a future date?
-
For PCI DSS, can multi-factor authentication (MFA) implementations indicate the success of a factor prior to presentation of subsequent factors?
-
What is the completion date for PCI DSS assessments documented in a Report on Compliance and its related Attestations of Compliance?
-
What is the completion date for PCI DSS assessments documented in a Self-Assessment Questionnaire and its related Attestations of Compliance?
-
How does PCI DSS Requirement 6.4.3 apply to 3DS scripts called from a merchant check-out page as part of 3DS processing?
Most Recently Updated
-
When should an entity implement PCI DSS requirements noted as best practices until a future date?
-
What is meant by "At-Risk Timeframe" and at risk referenced in the Final PFI Report?
-
Does PCI DSS Requirement 8.2.2 allow users to share authentication credentials?
-
For PCI DSS, can multi-factor authentication (MFA) implementations indicate the success of a factor prior to presentation of subsequent factors?
-
What is the completion date for PCI DSS assessments documented in a Report on Compliance and its related Attestations of Compliance?