For many organizations, storing primary account numbers (PAN) has a significant impact on network security. Over the years, many major data breaches have occurred as businesses focused on storing PANs for fast access on their servers.
Many businesses affected by data breaches use the customer convenience rationale to store PAN data on their networks. However, these companies using this reason are also not compliant with the Payment Card Industry Data Security Standard (PCI DSS) because the PCI DSS requires, for some reason, merchants not to store tracking data.
Storing customers’ full PAN data exponentially increases the security risk to your business and, consequently, extends PCI compliance scope. Therefore, unless you have a commercial reason to store PAN data, do not store it!
See Also: How Can I Protect Stored Payment Cardholder Data?
Requirement 3 of PCI DSS is concerned with securing stored cardholder data. The six sub-requirements of PCI DSS requirement 3 provide detailed instructions on how merchants should store various information, including cardholder name, card account number, CVC code, and expiration date.
PCI DSS requirement 3.4 explicitly stipulates making the PAN unreadable wherever it is stored. Cardholder data is stored, including portable digital media, backup media, logs, and wireless network data collected or stored. Powerful one-way PAN hash functions, robust cryptography, truncation, index tokens, or technology solutions for this requirement can be used to render PAN data unreadable.
The only way to not be subject to PCI DSS Requirement 3 is not to store cardholder data! As mentioned above, storing PAN data increases your organization’s scope of compliance.
What is PAN, and how to make it unreadable?
PAN stands for Primary Account Number and is an essential piece of cardholder data that you must secure under PCI DSS. Storing complete PAN data from customers exponentially increases your company’s security risk and, therefore, compliance coverage. So unless you have a commercial reason to store PAN data, do not keep it!
See Also: How To Store Credit Card Information
A common misconception is that all elements of cardholder data must be encrypted when stored. It is PAN that needs to be encrypted. On the other hand, sensitive authentication data (SAD) can never be held by merchants.
See Also: HSMs for PCI DSS Compliance
PAN is the critical element for processing cardholder data in general. If the cardholder’s name or expiration date is not specified on the card, there may be cases where the PAN is not considered as cardholder data. This is not always the case, however, so merchants should build their data networks to match and work with the most prevalent form of customer data from PAN.
Below are some of the most common ways to make stored information unreadable, especially primary account numbers (PANs).
Masking of a PAN
Masking is all about keeping data private when introduced to an individual. Practically, anyone who uses a payment card in a store and then checks a printed receipt knows the masking process; specific PAN numbers are represented as Xs rather than real numbers. PAN masking should have the minimum number of digits required to perform operational functions by PCI DSS Requirement 3.3. The PAN mask should not exceed the first six and the last four digits.
When displayed, mask the PAN, and only personnel with a valid business requirement can view the entire PAN.
PCI DSS Requirement 3.3 deals with the protection of PAN displayed instead of being stored. The data could be stolen by an unauthorized or malicious entity if a complete PAN is seen on computer screens, paper receipts, faxes, records, or printouts. They can use this information to perform fraudulent transactions.
By displaying a full PAN only to people for business reasons, your organization will minimize the risk of malicious people stealing or accessing PAN data.
According to the PCI DSS, the masking approach should always ensure that only a minimum number of digits are shown to perform a specific business function. For example, if it requires only the last four digits to perform a job function, mask the PAN so that only the last four digits can be seen by people performing that function.
Truncation of a PAN
The truncation can be defined as the act of shortening the Primary Account Number (PAN). It is an acceptable method of making cardholder data unreadable if stored and permanently removing some of the data stored in files, logs, and databases.
See Also: What are the Acceptable Formats for Truncation of PAN
It should be noted that truncation is a persistent process and is different from PCI-DSS requirement 3.3. While truncation means making PAN unreadable when stored, PCI DSS requirement 3.3 refers explicitly to temporarily masking data when a paper is viewed on receipts or displays.
There is more than one truncation method acceptable according to the PCI Security Standards Council. Key points about PAN truncation are as follows:
- The data cannot exceed the first six last four digits of the PAN to consider properly truncated PAN data for storage in a PCI-DSS compliant manner. After removing the middle six numbers, PAN is no longer considered cardholder data and deemed unreadable.
- PAN truncation can replace data with “x” or “0” instead of truncated middle digits. More importantly, hashing cannot be used to replace the truncated segment of PAN. The benefit of this is that if the process is stopped, the encrypted card data is unreadable. The information means nothing to anyone except the processor holding the decryption key.
- The industry standard is to remove the middle six digits, but there are some differences in each of the major card brands’ rules. Organizations looking for flexibility in this area should review individual requirements for each card brand. They need to consider the purpose for which the data will be used and internal and external restrictions.
The truncation process makes the stored data unreadable, making sure that only a fraction of the entire PAN is stored. As with masking, no more than the first six and last four digits can be stored.
The truncation permanently removes some of the PAN data. Thus, only a fraction of the PAN is stored (must not exceed the first six and last four digits). PAN truncation is a common approach used in Card-Not-Present (CNP) transactions to combat credit card fraud globally.
PAN Truncation provides advanced security and protection to cardholders and merchants against damage caused by card data theft misuse. Truncation means that the full card number cannot be used in the future. The truncation process’s internal operational control may have a small effect on customer purchasing patterns but ultimately makes the payment process more secure.
One-Way Hashing of a PAN
A hash function is a well-defined, demonstrably secure cryptographic mechanism that converts PAN into a specific and unique array of data. In other words, each PAN provides a different result in hashing.
The one-way hash method is irreversible. It is widely used to ensure that the data is not changed, as any change in the original data block will result in a different hash value. The hashing method allows for secrecy, but like truncation, the stored data is impossible for future processing.
In your cardholder data system, you cannot preserve truncated and hashed versions of the same card unless you make additional checks to ensure that the two versions cannot be correlated to restore PAN.
According to PCI DSS requirement 3.4, if you store both the hashed and truncated PAN (card number), it must have additional controls to prevent their correlation. Hash and truncated PAN correlated with a short code can easily be coerced with brute force, and the attacker can reconstruct the original PAN.
To ensure correlation, the attacker needs to know the first 6, last four digits of the card number, and then brute-force only ten digits. This will be very easy as the card number length is only 16 digits.
The easiest way to comply with PCI DSS requirement 3.4 is to store truncated PAN and hash separately and use a salt hash.
Examples of methods you can use to avoid correlation are as follows:
- A unique, powerful, and secret input variable (salt) must be used for each hash so that two hashes of the same PAN have different values.
- Separate storage systems should be used for PANs isolated from each other using methods such as segmentation and separate access controls, one hashed and the other truncated.
- File/database systems must be configured to avoid cross-reference or link presence between hashed and truncated PAN.
- Real-time monitoring and dynamic protection systems should be used to detect and prevent access requests to associated PAN values.
The above examples are given as suggestions, and the methods are not limited to the above. Whichever methods are used, it should prevent unauthorized persons from associating between a hashed PAN and a truncated PAN.
A one-way hash is useful, even if it is irreversible, as you can use it to verify the PAN without revealing the card number.
Tokenization of a PAN
Tokenization is the method of preserving sensitive information by replacing it with a number called an algorithmically generated token. To avoid credit card fraud, tokenization is also used.
See Also: What Is Tokenization and How Does It Affect Your PCI Compliance?
The primary account number (PAN) of the customer in credit card tokenization is replaced by a randomly generated string of numbers called “tokens.” The actual bank account number is stored in a protected token vault.
See Also: Advantages of Using a Credit Card Vault for PCI
Tokenization is a mechanism that replaces proxy data for the original PAN. The result is a token that may look like a valid PAN, but that doesn’t make any sense to the attacker. The method is reversible in most applications; tokens can be recycled to original PANs on request. Tokenization is used if stored PANs need to be available for future transactions.
Tokens, followed by two common strategies, can be generated in a variety of ways:
- Indicators explicitly derived from the initial PAN value: This approach yields the same token for each given PAN in a mechanism that is expected to be deterministic.
- Randomly generated tokens: This approach generates different tokens each time, except that previous PANs are extensively searched to reconstruct a given token.
In other cases, the degree to which the marking process is decisive may be important. It all depends on whether the tokens are used or not. In some cases, it is desirable to keep the PAN format and other PAN numbers throughout the tokenization process.
Encryption of a PAN
Encryption targets are similar to tokenization in several ways, replacing PAN data with data of no inherent value to the attacker. Encryption uses uniform cryptographic algorithms and keys to extract original data from encrypted PAN. Algorithms are well known, so transaction security depends on cryptographic key strength and processing.
Generally, the encryption method changes the data format, and data size increases when data is encrypted. For the same purpose, tokenization helps preserve the original PAN data structure to ignore changes in existing systems.
Choosing the right encryption algorithms and associated key management practices simplifies the implementation of controls for PCI DSS. Complicating things will certainly deter attackers, but it will also increase the chances of a security loophole.
For key management, there are several considerations, including who owns the keys, how keys are created and distributed, problems such as the rotation process, and how keys are secured should be carefully considered when stored.
Without the proper use of the keys throughout their lifecycle, the keys can be disclosed, changed, or replaced by unauthorized personnel who could later capture sensitive cardholder data.
Suppose the PAN data the merchant is using is encrypted. In that case, the QSA will need to verify that the merchant uses an industry-accepted encryption protocol to ensure full compliance with PCI requirement 3.
Conclusion
Keeping PAN data increases your organization’s compliance with PCI laws and guidelines. When required for business purposes, the cardholder name, PAN, expiry date, and service code may be retained for as long as PCI DSS requirements secure them.
See Also: What are the PCI DSS Data Retention and Disposal Requirements?
Whatever approach traders plan to use to make their stored data unreadable, they need to be secured by associating them with encryption keys or index tokens.
Merchants must establish a data retention and storage policy that limits storage and retention time for strictly necessary business, legal or regulatory purposes. Sensitive authentication data, even if this data is encrypted, can never be stored after authorization.
For detailed information, you can review the PCI DSS Data Storage Dos and Don’ts document.
Like!! Thank you for publishing this awesome article.