FAQ #1308 Diff
How can an entity ensure that hashed and truncated versions cannot be correlated, as required in PCI DSS Requirement 3.4?
Earlier Version
Later Version
Removed
Added
The simplest approach for meeting this requirement is to not store hashed and truncated PAN. If, however, an entity wishes to store both hashed and truncated PAN, additional controls are needed to provide assurance that there is no single point where the two types of PAN formats could be captured for correlation. Examples of methods that may be able to meet the intent of this requirement include:
- Use of a unique, strong and secret input variable (e.g. salt) for each hash such that two hashes of the same PAN would have different values
- Use of separate
The simplest solution is not to store both hashed and truncated PANs. If both must be retained, the following controls can help:
Use of strong, unique, secret salts for hashing
Separate storage systems
- Configuring file/database systems to prevent the existence of any
- Use of real-time monitoring and dynamic response to detect and prevent requests to access correlating PAN values.
These examples are provided as suggestions; entities are not limited to only the above methods. Whichever methods are used, they should prevent unauthorized persons being able to correlate a hashed PAN to a truncated PAN, and be appropriate for the entity's environment
Real-time monitoring to detect correlation attempts
These are examples only. Controls should be suitable for the environment and ensure that full PAN reconstruction is not possible.
As per the guidance listed in PCI DSS implementing keyed cryptographic hashes with associated key management processes and procedures in accordance with Requirement 3.5.1.1 is a valid additional control to prevent correlation.
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.