FAQ #1435 Diff
What is the Council's guidance on the use of SHA-1?
Earlier Version
Later Version
Removed
Added
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.
Our document library can be accessed on our website at: https://www.pcisecuritystandards.org/document_library/
Disclaimer: This FAQ has been processed for display on this website and may contain errors. Please check the original FAQ on the PCI SSC website for the authoritative version.