Frequently Asked Question

How can an entity ensure that hashed and truncated versions cannot be correlated, as required in PCI DSS Requirement 3.4?
In order to meet PCI DSS Requirement 3.4, entities with both hashed and truncated versions of a PAN in their environment are also required to implement additional controls to ensure that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.
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:
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 storage systems, one for hashed and one for truncated PANs, that are isolated from each another using segmentation, separate access controls, etc.
- Configuring file/database systems to prevent the existence of any cross-references or links between a hash and a truncated PAN
- Use of real-time monitoring and dynamic response to detect and prevent requests to access correlating PAN values.
November 2014
Article Number: 1308
Related
-
How should PCI DSS v4.x requirements noted as superseded by another requirement be reported after 31 March 2025?
-
Are providers of third-party scripts for e-commerce environments considered third-party service providers for PCI DSS Requirements 12.8 and 12.9?
-
Why do requirements 8.3.9 and 8.3.10.1 focus on passwords/passphrases used for single-factor authentication, when multi-factor authentication is required for all access into the CDE?
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
-
How should PCI DSS v4.x requirements noted as superseded by another requirement be reported after 31 March 2025?
-
Are providers of third-party scripts for e-commerce environments considered third-party service providers for PCI DSS Requirements 12.8 and 12.9?
-
Why do requirements 8.3.9 and 8.3.10.1 focus on passwords/passphrases used for single-factor authentication, when multi-factor authentication is required for all access into the CDE?
-
Do PCI DSS Requirements 8.3.9 and 8.3.10.1 apply to all system components?
-
Is the cardholder in scope for PCI DSS?
Most Recently Updated
-
How should PCI DSS v4.x requirements noted as superseded by another requirement be reported after 31 March 2025?
-
Are providers of third-party scripts for e-commerce environments considered third-party service providers for PCI DSS Requirements 12.8 and 12.9?
-
Why do requirements 8.3.9 and 8.3.10.1 focus on passwords/passphrases used for single-factor authentication, when multi-factor authentication is required for all access into the CDE?
-
Do PCI DSS Requirements 8.3.9 and 8.3.10.1 apply to all system components?
-
Is the cardholder in scope for PCI DSS?