Welcome to a new year. I have had a number of interactions with a variety of people over the previous year and it has become obvious that the concepts of pre-authorization and post-authorization data is not clear to a lot of people. These two concepts are a key part of understanding PCI compliance. I will start with pre-authorization in this post and have a separate post for a discussion of post-authorization.
Pre-Authorization
Where pre-authorization (aka “pre-auth”) typically comes up is when someone asks, “How does [pick your online merchant] store a customer’s payment data and still be PCI compliant?”
Before we get to that question, we need to define what we mean by “pre-authorization”. Pre-authorization is that time when a merchant has a customer’s sensitive authentication data (SAD) or cardholder data (CHD) but has not yet processed it for payment.
For most merchants, that time between collecting the SAD/CHD and processing it is measured in seconds. For card present (CP) transactions, the SAD can be in the form of chip or magnetic stripe data. For card not present (CNP) transactions, it typically includes the cardholder name, primary account number (PAN), expiration data and CVV/CVC/CID. Regardless of transaction type, the data is sent off to either be approved or declined in seconds.
However, there are situations where that does not always happen that quickly. Mail order telephone order (MOTO) and facsimile orders are the most obvious examples that can extend the amount of time between receipt of the CHD and processing by minutes, hours or even days and weeks.
But there are some not necessarily obvious situations where processing delays occur.
My first example of delay is when you go to fill your car with fuel. When you swipe your card to pump the fuel, the system that manages the payment process will pre-authorize the purchase and then temporarily store the SAD until you finish pumping and hang up the hose to complete the transaction. When you complete the transaction at the pump, the system sends through the actual charge and securely deletes your SAD from the system. Depending on the size of your vehicle’s fuel tank and how close to empty you were, the system could have your SAD for quite a few minutes.
Another example is for the hospitality industry. In the hospitality industry, a reservation typically does not cause a charge until a customer checks out even though they are required to have a card on file to hold the reservation. When a customer checks into the property, the hotel’s billing system records the SAD and may also pre-authorize charges, but the actual card transaction is not processed until the customer checks out. As a result, hotels can have SAD on file for the length of a traveler’s stay. In fact, I have encountered SAD in hospitality systems that have been stored for more than a year due to reservations for special occasions such as graduations, birthdays, family reunions and anniversaries.
But getting back to the original question, the example that usually draws the most questions is in regards to when you, as a customer, store your card information with a merchant for future purchases. These entities store your payment information (pre-authorization) in their applications so that you or they can quickly pay for your purchases without constantly re-entering your payment information. These applications are not always part of a payment application, so they may or may not be PA-DSS validated. However, when encountering them, I use the PA-DSS standard to ensure they process, store and transmit the SAD/CHD securely. In addition, as a customer, you should have explicitly approved of the merchant storing your payment data and know how they will use that data.
Last, but not least, another great example of pre-authorization data are eWallet applications such as Google Pay and Apple Pay. eWallets are just an electronic version of a consumer’s physical wallet. eWallets are not regulated by the PCI standards or the card brands nor are they required to be PA-DSS validated. Not that these eWallet applications are not secure, it is just that there is no one independently validating that they are secure. That said, I always instruct developers of eWallet applications (or any pre-authorization applications) to follow the PA-DSS for developing a secure eWallet application.
The most confusion I encounter over pre-authorization data typically occurs regarding SAD/CHD that an organization receives via email or instant messaging. A lot of QSAs get their undies in a bunch over when this happens and point to requirement 4.2 as the reason why this is unacceptable. As a refresher, requirement 4.2 states:
“Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat, etc.).”
The operative word in 4.2 is “send”. Requirement 4.2 says nothing about receiving PANs by these methods. That does not mean that the Council recommends receiving PANs via email, IM or similar methods. It is only recognition of what goes on in the real world. There will always be a small percentage of people that will send their cardholder data insecurely and there is little an organization can do to stop it.
Yes, you can put a data loss prevention (DLP) solution in the middle of all of these messaging technologies and catch the bulk of the offenders. But then what?
I have some clients who have taken this approach and the DLP securely deletes the message and triggers a message back to the sender stating that they do not accept payment card information via this communication channel and then explains all of the appropriate and approved ways a customer can communicate SAD/CHD.
I have other clients that use the DLP but do not delete the message. They explain that in this one instance, they will process the transaction because they are all about the customer experience. They have a process that they follow to handle the message and then securely delete it.
To keep your email, IM and other messaging systems out of scope, the Council has told QSAs that organizations must have a policy in place that says they never encourage customers to use these messaging channels for communicating SAD/CHD and to make sure that organizations have a process to remove the SAD/CHD as soon as possible from those systems. That typically involves the printing of the message, deleting the message from the system(s) and then securely destroying the printed message once the transaction is processed. This is all considered “incidental contact” in the eyes of the Council and the QSA can then consider the system out of scope as long as they can satisfy themselves that the manual process is reliable.
The bottom line is that all of these situations involve pre-authorization data and pre-authorization data can include everything recorded on a card’s track or chip. If a merchant does store the pre-authorization data for the convenience of their customers, they are obligated under the PCI DSS to store it separately, away from post-authorization data and to protect it with the same rigor as post-authorization data, i.e., encrypted, extremely limited access, logging, monitoring, etc.
That is a key point that is often missed. Pre-authorization data must be stored separately and away from any storage of post-authorization data. That means that separate instances of databases need to be used on separate servers. The rationale for this is no different than keeping key encrypting keys (KEK) away from data encrypting keys (DEK). It is to ensure that in the event of a breach of post-authorization data, it does not readily lead to a breach of pre-authorization data. It also allows for more rigorous controls over the pre-authorization data.
One final point regarding pre-authorization data that I made earlier, but it needs to be reiterated. If a merchant intends to store pre-authorization data, I highly recommend that you have a legal agreement in place between your organization and your customers that explains why your organization is retaining this information and the business purpose(s) for which the information will be used. That can be similar to a license agreement that the user either signs or clicks “Okay” online to acknowledge their approval.
In a future post I will discuss the world of post-authorization where the PCI standards were originally focused.