Many web developers and software programmers design platforms that require digital payments. It is important that developers of payments solutions understand how and why their solution handles cardholder data (CHD). There are many reasons why a solution might want to store that data, either short or long term, including payment processing, transaction history, or recurring billing. Consumers assume that merchants and financial solutions will handle this data in a secure manner to thwart theft and prevent unauthorized use. The reality is that many merchants may not be aware that they are storing CHD. Industry research indicates that up to 67% of merchants today are storing unencrypted cardholder data.
The Payment Card Industry Data Security Standard (PCI-DSS) is a widely accepted set of policies and procedures intended to optimize the security of credit, debit and cash card transactions and protect cardholders against misuse of their personal information.
A set of requirements set forth by the PCI Security Standards Council (PCI-SSC) and supported by the major card brands, PCI-DSS requirements apply to all entities that store, process or transmit cardholder data. PCI-DSS requirements state that cardholder data can only be stored for a “legitimate legal, regulatory, or business reason.” In other words: “If you don’t need it, don’t store it.”
Those with a legitimate business reason to store cardholder data must understand what data elements PCI-DSS allows them to store and what measures they must take to protect that data.
It is important to note that these statements apply to Cardholder Data (16-digit Primary Account Number, expiration date, cardholder name), and do not apply to Sensitive Authentication Data (Track Data, PIN, PIN Block, CVV). Sensitive Authentication Data (SAD) can never be stored after authorization.
If cardholder data is to be stored, PCI compliance requirements state the cardholder data must be rendered unreadable using industry standard techniques.
Credit Card Data: What is Allowed to be Stored
Validating entities are permitted to store data classified as Cardholder Data (CHD). This data includes the 16-digit primary account number (PAN), as well as cardholder name, service code, and expiration date. Traditionally, this data is located on the front of the card (EMV chip data is not Cardholder Data and cannot be stored after authorization).
Credit Card Data: What is Not Allowed to be Stored
Sensitive Authentication Data (SAD) can not be stored after authorization of a transaction. This data includes the full magnetic stripe data found on the back of the card, as well as any equivalent data on the EMV chip or elsewhere. SAD also includes the CVV (or equivalent data) as well as the PIN and PIN block. This data is extremely valuable to attackers for use in both card-present and card-not-present environment.
PCI Requirements for Storage of Cardholder Data
The PCI-DSS is defined by twelve PCI requirements, broken down over 220 sub-requirements. For the purposes of this discussion, we will focus on Requirement 3: Protect stored cardholder data.
Requirement three can be broken down over multiple sub-requirements. The overarching principle is that limiting, prohibiting, and deleting stored cardholder data eliminates a key target for cybercriminals. Merchants that do not store cardholder data are much less likely to suffer an expensive, time consuming, and reputationally damaging breach of their customers’ personal data.
It is important to know the definitions and differences between Account Data, Cardholder Data, and Sensitive Authentication Data. Account Data represents all the data that can be found on a credit card. Account Data is further broken down into either Cardholder Data (CHD) or Sensitive Authentication Data (SAD).
Cardholder data (CHD) includes the 16-digit PAN, expiration date, and cardholder name. This data is traditionally (but not always) represented on the front of the card. Storage of cardholder data should be limited to what is necessary to meet legal, regulatory, or business needs.
Sensitive Account Data (SAD) includes the sensitive track data held by the magnetic stripe, CVV, PIN, and PIN Block. This data can never be stored after authorization. The only entity that may store SAD is an issuer, and only under specific conditions and rationales.
PCI Rule 3.1
PCI-DSS requirement 3.1 lays out the methodology necessary to ensure that cardholder data is limited to that which is necessary for legal, regulatory or business needs. This requirement states that validating entities must develop data retention policies, secure deletion policies, as well as a quarterly process to identify and remove any cardholder data that exceeds the retention period. This quarterly process is required whether or not the entity is aware they are storing cardholder data. There are many tools and techniques that can be used to identify this data. Most common is the use of a data discovery tool combined with best practices to protect against a physical compromise.
PCI Rule 3.2
PCI-DSS requirement 3.2 states that Sensitive Authentication Data (SAD) cannot be stored after authorization, even if it is encrypted. (Encryption changes plaintext into ciphertext.) SAD includes the full track data, CVV, and PIN data. This data is extremely valuable to attackers for use in fraudulent transactions over both card-present and card-not-present transactions. The only entities that can store this data are issuers with a legitimate business need related to the issuing services. Validating entities must create a cardholder data flow diagram documenting where and how cardholder data moves through the system and/or is stored.
PCI Rule 3.3
PCI Requirement 3.3 states that the 16-digit Primary Account Number (PAN) must be masked when displayed. The maximum that can be displayed are the first six and last four digits. The full PAN can only be displayed for those users whose roles include a legitimate business need to view the full PAN. This requirement applies to displays of PAN on screens, paper receipts and other printouts.
PCI Rule 3.4
If the storage of PAN is unavoidable, that data must be rendered unreadable wherever it is stored. The PCI-DSS explicitly enumerates the acceptable methods for rendering this data unreadable. These methods include:
- Strong one-way hash functions of the entire PAN
- Also called the “hashed index”, which displays only index data that point to records in the database where sensitive data actually reside.
- Truncation
- Removing a data segment, such as showing only the last four digits.
- Index tokens with securely stored pads
- An encryption algorithm that combines sensitive plain text data with a random key or “pad” that works only once.
- Strong cryptography
- Cryptography is defined as the use of mathematical formulas to render plain text data unreadable.
Rendering PAN data unreadable means that if an attacker were to get the data, it would be extremely difficult and time-consuming to decrypt the data. This means that data becomes essentially useless to attackers.
PCI Rule 3.5
PCI rule 3.5 expands on the use of cryptography and requires that validating entities take the necessary steps to protect encryption keys from disclosure and misuse, and document those procedures. If an attacker gets ahold of the encryption keys, the data can be decrypted. This applies to data encrypting keys as well as key-encrypting-keys, to limit the possibility of attackers using any of these keys to decrypt data and expose cardholder data. Cryptographic keys must be stored in the fewest locations possible, with the least number of individuals having access. Validating entities must consider both external threats (hackers, physical threats) as well as internal threats from employees.
PCI Rule 3.6
Key management processes for the use of cryptographic keys must be fully documented. This includes the secure generation, distribution and storage of cryptographic keys as well as policies that require key changes at the end of the cryptoperiod or if the integrity of the key has been weakened. This weakening could result from a team member with knowledge of the clear text encrypting key departing the organization, or if the keys are suspected to be compromised.
Conclusion
Developers of payments solutions must make sure they understand how and why their solution handles cardholder data (CHD), and they must also ensure PCI-DSS compliance for storing credit card numbers in a database. By keeping these tips top of mind, developers can help protect sensitive cardholder data from falling into the wrong hands. Contact us today to learn how we can help you with PCI compliance.
Richard Rohena
Manager of PCI Compliance Services
