Upcoming changes to the Payment Card Industry Data Security Standard: New hashing requirements
Published by Governance, Risk and Compliance on 19 August 2022
Organisations that are subject to the Payment Card Industry Data Security Standard (PCI DSS) should be aware of changes to the Standard in order to ensure they remain compliant with the updated requirements.
Key changes to the Standard are outlined here.
What is the Payment Card Industry Data Security Standard (PCI DSS)?
The PCI DSS is a compliance standard that applies to most organisations that accept credit card payments.
It further applies to those providing relevant services such as payment processors, or cloud based infrastructure providers) to those merchants.
A significant update to this standard (v4.0) was announced in March 2022, with most changes slated with an effective date of 31 March 2025.
Be Prepared
Organisations that require PCI DSS compliance must ensure they understand how the updated Standard will affect them.
While much of the new regulatory regime is not enforceable before 31 March 2025, organisations and businesses would be remiss to wait too long before:
- Assessing what these changes mean for them;
- Scoping new work; and
- Ensuring that budget has been secured to deliver.
It really is a case of fail to prepare, prepare to fail.
Who This Affects
All merchants and in scope service providers need to assess the changes to PCI DSS.
The changes to hashing will primarily affect service providers and in some cases large merchants.
Protecting Personal Account Numbers
Key amongst the changes to the Standard are new expectations associated with the protection of credit card numbers.
Under the Standard there are three ways to protect Personal Account Numbers (PANs). PANs can be:
- Encrypted;
- Truncated; or
- Tokenised.
Let’s look at the last two.
Most people are familiar with truncated PAN, where enough of the credit card number is displayed to allow for it to be recognised. For example, you might see the first six digits and the last four digits on a receipt or at a payment gateway.
Tokenised PANs are used in place of the credit card number where possible in payment processing.
Reducing the processing, storage, and transmission of the actual PAN can reduce the risk of a credit card breach and leaves your organisation less exposed to liability for protecting this payment information under the Standard.
Hashing PANs
In many cases hashing is used in the tokenisation process.
For the uninitiated, hashing occurs when we take the PAN and turn it into a hash which cannot be converted back into the original credit card number. In this regard, encryption differs from hashing in that it is possible to recover the original credit card number from an encrypted PAN by using a decryption method.
However, it is worth noting that there are ugly, brute force methods which can de-hash a hashed PAN.
This is most easily achieved when a truncated PAN and a hashed PAN are stored together; a risk that was highlighted by the Payment Card Industry Council:
“It is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed version of a PAN.
Where hashed and truncated versions of the same PAN are present in an entity’s environment, additional controls must be in place to ensure that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.”
Requirement 3.4, Payment Card Industry Data Security Standard
Breaking It Down
Put simply, if an attacker has access to both truncated PAN and the hash of that PAN then they can find a way re-engineer the full original PAN (aka your credit card number).
This is achieved by creating a hash of every possible PAN and checking it against the starting hash. When the numbers match, they have got your credit card number.
Given an attacker would begin with a few of the credit card numbers in their correct position (pulled from the truncated PAN), the range of unknown numbers is significantly reduced.
It can be further reduced by checking whether potential PAN is a valid credit card, using the Luhn check.
Using a 64-core computer approximately 1000 PANs can be exposed in a second.
This means that a database of 10 million associated hashed and truncated PANs could be breached un three hours.
Whilst the Payment Card Industry Data Security Standard 3.2.1 r3.4 states that the truncated PAN and the hashed PAN should be kept apart, in practice this can be challenging to effect.
This may be why the Payment Card Industry Council have modified how PANs can be hashed.
New requirement
The Payment Card Industry Data Security Standard 4.0 states that:
“Hashes used to render PAN unreadable… are keyed cryptographic hashes of the entire PAN, with associated key-management processes and procedures”
This means if you have been using a hash function such as SHA-256 to create your tokens, you will be required to change to a hash-based message authentication code (HMAC) function.
Under the hood of a HMAC a hash function like SHA-256 is used but it also uses a secret key.
So, for an attacker to attempt a brute force attack on a HMAC they need to know the secret key before they can start guessing.
Key Management
Keeping that key secret is obviously critical which is why the updated Standard also specifies that key management is required.
The specifics of key management are defined in r 3.6.and 3.7 of Payment Card Industry Data Security Standard 4.0.
If your environment is hosted in the cloud, then using its key management service (e.g. AWS KMS) may be appropriate.
If based in a data centre, then a hardware security module (HSM) may be required to help securely store the HMAC secret.
Help is Available
CyberCX has extensive Payment Card Industry Data Security Standard experience and can provide advice on the impact of the updated Standard on your organisation.
CyberCX can also provide a range of PCI DSS services, including:
- Penetration testing
- Managed SIEM/SoC
- Managed vulnerability scanning
- Managed assurance
- Architecture and build
