A payment application designed to store both hashed and truncated PAN (card number) is required to have additional controls to prevent their correlation.
Many times, PCI DSS QSAs know the requirements but do not have examples/demonstrations to make customers understand the impact of lapse of the specific control. This blog is an example where QSA can make customers realize how easy it is to correlate hashed and truncated versions of the card numbers to obtain clear text PAN.
With less than 6 lines of python code, hashed and truncated PAN in correlation could easily be brute-forced and the attacker could get the original PAN.
To accomplish this, we should know the first 6, the last 4 digits of the card number, and then the attacker would have to guess (brute-force) only 10 digits. Since the card number length is only 16 digits, this should be very easy, and can also extend to other card lengths.
Please see below Proof of Concept (POC). This is for 1 test card number of 16 digits and SHA-512 hash. For multiple rounds of execution, average time is of approx. 1 sec to get the original PAN.
As a QSA, one should always ask the clients to store truncated PAN and hashed value separately and use a salted hash.
Per PCI DSS Requirement 3.4e, if the hashed PAN and Truncated PAN of the same credit/debit card number exists in the same environment, then there must be additional security controls present to prevent the reconstruction of original PAN.
There is further guidance provided by PCI SSC in their FAQ – How can an entity ensure that hashed and truncated versions cannot be correlated, as required in PCI DSS Requirement 3.4?
These QSA’s perform comprehensive PCI compliance assessments that relate to the protection of customer SAD such as PAN. To know more about protecting cardholder data and PCI DSS certification, visit our PCI DSS Certification page.
Credits:
Varun Kaushik
VP – APAC Continuous Compliance, ControlCase.