[in]security blog

Don’t Tie Yourself in Knots Thinking you can Store Payment Card Verification Codes/Values

Written by David Gamey | Aug 27, 2021 2:07:00 AM

Card Not Present Security Codes/Values are the 3 and 4 digit printed numbers on your payment cards used to verify card-not-present transactions. PCI DSS has been crystal clear for many years that payment Card Verification Codes/Values are Sensitive Authentication Data (SAD) and can't be stored after transaction authorization except by card Issuers. Specifically PCI says:

  • "Do not store sensitive authentication data subsequent to authorization (not even if encrypted)" (DSS v1.0 2005)
  • "Sensitive authentication data must not be stored after authorization, even if encrypted. This applies even where there is no PAN in the environment." (DSS 3.0 2013)
  • "It is permissible for issuers and companies that support issuing services to store sensitive authentication data if there is a business justification and the data is stored securely." (DSS 2.0 2010)
  • "Only issuers or those providing issuing services may have a legitimate business need to store SAD after an authorization." (FAQ 1280)
  • Non-issuers handling SAD must ensure they have "processes for securely deleting the data to verify that the data is unrecoverable." (DSS 2.0 2010)

Despite this, we occasionally encounter entities storing security codes/values that fit neither of these use-cases. Almost universally, these entities believe they have a compelling justification or loop hole that allows them to store these codes/values. We’ve heard many arguments and seen people trying to rationalize this untenable position. Please, read this article before you get yourself tied up in logical knots.

For some reason, people who clearly see why storing track/track equivalent, or PINs/PIN blocks is prohibited get hung up on the issue of storing security codes/values. No matter how many clarifications and debates on this subject can be cited, someone always tries to push the compliance envelope by word-smithing, analogy, or shear force of will. Every time we have been party to one of these debates (and we’ve seen quite a few), you can see the phases of SAD storage denial: real or feigned ignorance, surprise, rationalization, desperation, escalation, coupled with a range of logical fallacies. Even when the debater realizes they are wrong, some will try bizarre arguments to find cover for their position. We’ve seen people tie themselves in logical knots trying to avoid remediating security code/value storage. To help address this, the PCI SSC recently issued FAQ 1533 which is specifically intended to put an end to these debates by answering why this isn't allowed. Here is a recap of the common questions we've encountered about the storage of SAD and security code/values:

  • I’m an issuer or service provider to an issuer, can I store SAD to support my issuing processes? Yes, if it's for your cards and for legitimate issuing support.

  • I'm a merchant, merchant service provider, processor, or other non-issuer:

    • Can I store SAD pre-authorization? Yes, however you must securely purge any storage immediately after authorization.
    • Can I store SAD for a wallet or recurring payment? No, never. (see FAQ 1280)
    • Can I store SAD for another reason? No, never.
    • Can I store SAD in this other (fill in the blank) scenario? No, never.
    • Can I store the security code/value digits when no pan is present? No, never.
    • Can I store SAD if I talk my acquirer into storage being low risk? No, never.

People will try a variety of arguments to escape the rules to rationalize storing security codes/values. The debaters arguing this case are usually guilty of multiple logical fallacies. The situation will not end well if they stay their course. Some examples:

  • Documentation from (or discussion with) a reliable source said that we could store this. An unfounded Appeal to Authority, the problem with reliable sources is that they are not necessarily authoritative sources. We have seen a number of cases where service providers, acquirers, banks, and even groups within payment card brands have communicated that it was ok to store security codes/values. These communications have been both verbal and documented; however, frequently they come from groups with no authority (e.g. marketers, developers, etc.) or are incomplete with respect to the two acceptable use-cases.
  • It’s not sensitive if it’s not stored with PAN. Or, if it isn't stored with PAN then it can’t be used. So what’s the problem? Special Pleading, or simple ignorance. It's untrue. If it were true, the entity making the argument could not use it and if they couldn’t use it they would have no reason to keep it. Again their argument tries to ignore correlation (see PCI DSS, FAQ 1533). A simple test is if you store card security codes/values and can later use them with PAN then you are non-compliant.
  • So if I have a table of all the numbers from 0 to 9999 then we'd be non-compliant. An Appeal to Ridicule or simple exaggeration. It ignores correlation (see FAQ 1533).

There are only two other complications that you need to be aware of:

  • Legal constraints (which must be vigorously demonstrated), and
  • Call recordings (see FAQ 1210 and the Telephony Information Supplement below). Extracting searchable card data from audio recordings with modern technology ranges from trivial for DTMF tones to relatively simple for voice. Any compensating controls for this need to be exceptional and agreed with your QSA. We recommend they also be discussed with your acquirer or the card brands.

The bottom line is that, if you process or transmit card security codes/values it’s in scope and must be treated as sensitive authentication data. You cannot store it after transaction authorization unless you are an issuer and storing it for issuing reasons. Not ever, not encrypted, not hashed, not tokenized, not indexed, not separated from PAN, not with any possibility of correlating or reconnecting the PAN and security code.

Learn More
View full post