The Basics of Storing PAN Data

‍

While the only Pan you might currently know is Peter, you should also get to know and understand the acronym PAN if your business accepts credit cards. PAN stands for Primary Account Number, and it is a key piece of cardholder data you are obligated to protect under the PCI DSS.

‍

Storing customers’ full PAN data exponentially increases your business’s security risk and, consequently, it’s scope of compliance. Therefore, if you don’t have a business reason to store PAN data, then don’t store it!

‍

If you have to store PAN data, then PCI DSS Requirement 3.4 requires that you render it unreadable and unrecoverable through one of the following methods:

‍

• One-way hashes based on strong cryptography (hash must be of the entire PAN)
• Truncation (hashing cannot be used to replace the truncated segment of PAN)
• Index tokens and pads (pads must be securely stored)
• Strong cryptography with associated key-management processes and procedures.

‍

One-way hashing is useful because, although irreversible, you can use the hash to validate the PAN without exposing the card number.

‍

Here are a couple examples of hashing in action:

‍

• Card-not-present transaction with card-present verification at time of pick-up: Say you buy a rail ticket online and then go to an unattended terminal at the station to pick up the ticket. The kiosk may ask you to insert the card that was used to buy the ticket to make sure that you have a physical card. Now, to avoid storage of PAN data, the rail vendor may choose to store only hashed values. At the time of the ticket pick-up, the PAN of the inserted card can be hashed and the hash value can be compared to the one of the card used to purchase the ticket online (these should match).
• Recurring payment transactions: Another example is a Fraud Management system that stores hash values of PAN data in order to be able to identify all transactions made with the same card (the hash value of the same PAN will always be the same). By storing only hash values of PAN data within the Fraud Management system you are not exposing real PAN data, even to fraud analysts.

‍

Review the guidance within PCI DSS Requirement 3.4 for additional information on rendering PAN unreadable for storage.

‍

How PAN Storage Impacts Scope of Compliance

‍

The only way to not be subject to PCI DSS Requirement 3 (“Protect Stored Cardholder Data”) is to not store cardholder data! As mentioned above, storing PAN data increases your organization’s scope of compliance. This means you have more hoops to jump through when securing—and validating that you’ve truly secured—the PAN.

‍

The hashing process, for example, is reliant upon multiple variables when determining scope of compliance:

‍

“Are hashed Primary Account Numbers (PAN) considered cardholder data that must be protected in accordance with PCI DSS?”

‍

One-way hashing meets the intent of rendering the PAN unreadable in storage; however the hashing process and results, as well as the system(s) that perform the hashing, would still be in scope to assure that the PAN cannot be recovered. If the hashing result is transferred and stored within a separate environment, the hashed data in that separate environment would no longer be considered cardholder data and the system(s) storing the hashed data would be out of scope of PCI DSS. If however, the system hashes and stores the data on the same system, that system is considered to be storing cardholder data and is within PCI DSS scope. The difference lies in where the data is hashed and then stored. More on hashing: A hash is intended to be irreversible by taking a variable-length input and producing a fixed-length string of cipher text. As the PAN has been ‘replaced’, it should most often be considered out of scope in the same manner receipt of truncated PANs are out of scope. However, PCI DSS Requirement 3.4 also states that the hash must be strong and one-way. This implies that the algorithm must use strong cryptography (e.g. collisions would not occur frequently) and the hash cannot be recovered or easily determined during an attack. It is also a recommended practice, but not specified requirement, that a salt be included. Since the intent of hashing is that the merchant or service provider will never need to recover the PAN again, a recommended practice is to simply remove the PAN rather than allowing the possibility of a compromise cracking the hash and revealing the original PAN. If the merchant or service provider intends to recover and use the PAN, then hashing is not an option and they should evaluate a strong encryption method. Source: PCI Security Standards Council FAQs Page

‍

Need help aligning your business requirements with a reduced PCI scope?

‍

Securing stored PAN data—and doing so in a compliant manner—is a complicated endeavor, but if your organization has a true business need to do so then it’s worth it to get it right.

‍

For assistance with PCI DSS contact the VikingCloud team. We’d be happy to help.