Prior versions of the Payment Card Industry Data Security Standard (PCI DSS) permitted the use of hashes to render primary account number (PAN) unreadable while still allowing for confirmation or tracking of card data. PCI DSS version 4.0 has a new requirement, Requirement 3.5.1.1, which states that, in such situations, the hashing method used must be a keyed cryptographic hash.
This article outlines the risks created by hashing of cardholder data and explains how keyed cryptographic hashes address this risk.
Background
A Visa or Mastercard PAN consists of 16 digits. The first six digits are used as the bank identification number (BIN), which is a unique identifier assigned to financial institutions that issue payment cards. The PCI DSS allows these first six digits, as well as the last four digits, to be displayed on a receipt and stored without encryption. While American Express and Discover cards may use a different number of digits for the BIN or full card number, the approaches discussed in this article work similarly for those brands.
A hashing algorithm takes a piece of data, such as a credit card number, and runs it through a mathematical function that outputs a fixed-length string of data, referred to as a signature or hash. With a sound hashing function, you would (a) never expect to produce the same hash from two different data inputs and (b) never be able to “reverse” the math and determine an input dataset from the hash using a mathematical function.
The only way to reverse a sound hash is to brute-force guess potential inputs, run them through the hashing function and see if the output matches the target hash. This process is known as cracking and is often used to obtain passwords from stolen password hashes.
Attacking Credit Card Number Hashes
Let’s consider an attack in which a threat actor has stolen a copy of an ecommerce database containing order data, but not containing encrypted card numbers. Instead, the ecommerce database stores a SHA-256 hash of the full card number in one field and the last four digits of the card number in a separate field.
Initially it would seem that the threat actor would need to brute-force guess the first 12 digits of the card number, which would mean calculating 999,999,999,999 (i.e., almost a trillion) hashes. However, there are tricks that can be used to reduce this number.
As previously mentioned, the first six digits of the card number represent the BIN. Each issuing bank is assigned a different BIN, and it is not difficult to generate a list of potential BINs from data available on the Internet. So, the threat actor could speed up their attack by only generating cards with, say, the 500 most common BINs, rather than all 99,999 possible BIN combinations.
In addition, the last digit of the credit card number is a Luhn checksum, devised from a mathematical algorithm applied against all of the other digits, which is used to easily detect mistyped or similarly erroneous card numbers. If the threat actor only tests for 16-digit numbers with a valid checksum, they drop the number of options by a factor of 10.
As part of a recent card data breach investigation, Sikich performed a variation of this attack to identify credit card numbers associated with at-risk transactions. Sikich used about 6,000 common BINs associated with Visa and Mastercard cards together with a $5,000 server meant to be used for password cracking and, within 72 hours, successfully “cracked” over 95% of the full card numbers from a database containing 500,000 order records holding only the last four digits and a SHA-256 hash of each card number.
Keyed Cryptographic Hashes
PCI DSS version 4.0 addresses the risks related to the ability to reverse stored credit card hashes through these brute-force methods by requiring keyed cryptographic hashes. With a keyed cryptographic hash, the payment application generates a random string (the key) and combines it with the card data before the hash is generated. But do not confuse this key with a salt.
- With a salt, a different random string is generated for each input value. This salt significantly increases the effort required for brute-force cracking of passwords or other hashed data. But the salt only adds mathematical complexity, not secrecy. The salt is generally saved in clear text in the database next to the stored hash.
- With a keyed cryptographic hash, the key is treated the same way as any other cryptographic secret. It must be protected from disclosure, for example, by applying split knowledge and dual control or by making use of a hardware- or cloud-based secrets management vault.
Organizations that are currently storing hashes of card data will likely need to upgrade their systems to comply with the requirement for keyed cryptographic hashes in PCI DSS version 4.0. The good news is this requirement is considered a best practice until March 31, 2025, so organizations have some time to plan for and implement any necessary changes.
Should your organization have questions about navigating the new PCI DSS 4.0 requirements, please reach out to our Governance, Risk, and Compliance team and one of our Qualified Security Assessors (QSAs) will be happy to help.
