Pre-Authorization Data – The Card Brands Weigh In

I just wanted to pass along what I have heard thus far on this topic from the various card brands.  I’ll keep updating this post as I get more responses.

American Express (aka Trustwave) came back with the following.

“Per your inquiry regarding the storage of pre-authorized data, from what I can tell the American Express DSOP program currently does not address this topic. However, both the PCI SSC and the card brands (including American Express) have made it abundantly clear that pre-authorization data is to be protected with the same zeal as post-authorization data. That means encrypting it and restricting access to it. The reason the PCI SSC has not issued any directives regarding pre-authorization data yet is that it is a complicated environment and cannot be dealt with in a simple manner with the same approach working for all occurrences.

So, while pre-authorization data seemingly is not covered by the PCI DSS/DSOP programs at this time, you must do everything you can to protect it.

I hope this somewhat answers your question. I plan on doing more research to find any official documentation regarding the subject.”

MasterCard International followed up with their response.

“Merchants should talk with their acquirers to determine the pre-authorization rules particular to their vertical market and region.”

Visa quoted their Visa International Operating Regulations manual; section Account and Transaction Information Security Requirements VIOR 2.1.E (Updated):

“Ensure that all agents and Merchants do not store any of the following, subsequent to Authorization:
–    Full contents of any data taken from the Magnetic Stripe (on a Card, in a Chip, or elsewhere)
–    Card Verification Value 2 used to verify Card-Absent Transactions
–    PIN or the encrypted PIN block”

Discover has come back with the following.

“Currently the following restrictions apply:

(a) Sensitive Authentication Data obtained in connection with a Card Transaction must not be retained after receipt of an Authorization Response.
(b) Sensitive Authentication Data must not be recorded on Transaction Documentation or any other records or evidence of Card Transaction.
(c) Any processing, transmission, or storage of Cardholder Data must be conducted in accordance with PCI DSS requirements.”

JCB is still to be heard from.

I was deeply disappointed with MasterCard’s response.  Acquiring banks, for the most part, cannot answer basic questions about the PCI DSS, so we are supposed to believe that they are experts on retention of pre-authorization data based on a company’s vertical market and region?  Talk about passing the buck.

I am also surprised that I have yet to see any of the supposedly “very specific rules that prohibit any storage of sensitive authentication data (SAD) and do not make any exceptions.”  Not that I was expecting any as the Council has a tendency of making a mountain out of a molehill at times.

Based on the responses, I would highly recommend that merchants take American Express’ advice and protect pre-authorization data with the same voracity as they do with post-authorization data.

Merchant Beware – New Mobile Payment Solution Out In The Wild

Merchants need to be aware of a new mobile payment solution – Square from Square Inc.  A colleague pointed me to the Square site with the question, “Is this PCI compliant?”

Square appears to be a hardware/software solution for iPhones, iPads and Android devices.  It has a cute, square magnetic stripe reader for swiping cards, but also appears to provide the capability to manually enter cardholder data through these devices’ virtual keyboards.  This all appears to be similar to the iPhone that used to appear in the first Apple iPhone commercials that, for reasons that will become obvious, magically disappeared from their commercials very quickly and quietly.  It is also why Apple no longer uses iPhones or iPod Touches in their stores to process payments.

In referencing the PCI SSC’s PTS certification database, I could not find Square’s certification for the PTS standard.  Although, given the pictures on Square’s Web site, I really did not expect to find it certified to the PTS standard as there is no way it could meet the PTS standard.  Has Square submitted their solution for PTS certification?  It may have, but since the PCI SSC PTS certification database only lists those devices that have completed the certification process, there is no way for anyone to know if it has submitted Square until it is certified.  However, since the use of PTS certified devices is a requirement of all of the card brands, until Square is PTS certified, use of a Square device for processing of credit cards violates a merchant’s merchant agreement.  Game over.

While not complying with the PTS standard is a deal breaker in my opinion that is not the only PCI compliance issue.  In referencing the PCI SSC’s PA-DSS certification database, I could also not find the Square software application listed.  That situation was also not unexpected as the PCI SSC announced in a press release on June 24, 2011 that it was suspending the PA-DSS certification review of all mobile payment applications indefinitely.  As a result, there is no way Square’s software will be PA-DSS certified for the foreseeable future whether they submitted it for PA-DSS certification or not.  Not that the PA-DSS certification is a deal breaker for merchants to use the Square software, but it means that merchants using the Square software to process payments will have to have the Square software assessed to ensure it meets all of the PCI DSS requirements regarding payment applications.

And knowing what I know about all of these devices, I can guarantee that the Square software will not be PCI DSS compliant because all of these devices will store the cardholder data unencrypted for an untold amount of time until it is written over.  Even if Square’s software encrypts the data, the underlying OS will also collect the data in cleartext.  Forensic examinations of these devices have shown time and again that regardless of what the software vendor did, the data still existed in memory unencrypted.  And that unencrypted data in memory can exist in these devices for days, weeks to even months depending on transaction volume and other applications loaded on the device.  It is this surreptitious OS data collection activity, the security issues with other applications as well as other security concerns that caused the PCI SSC to suspend their PA-DSS certification activities of these applications.

There is only one solution that uses an iPhone or iPod Touch that is PTS and PA-DSS certified at this time and it is from Verifone.  The reason that Verifone’s PAYware solution is certified is that: (1) Verifone submitted it for the PCI certifications prior to the June 24 suspension and, the bigger reason in my book; (2) it relies on a digital back separate from the iPhone/iPod that performs the card swipe and all of the card data processing/transmission in a secure manner.  The iPhone or iPod Touch are used only as a display and cellular/Wi-Fi conduit for network connectivity.

The only other mobile payment solutions I am aware that are PTS compliant are purpose built credit card terminal using Wi-Fi or cellular communications.  These are considered terminals by the PCI SSC, so their underlying software is not required to be PA-DSS certified at this time, but they are required to be PTS certified.  In addition, these terminals have been in use in Europe for quite some time, so they are a proven secure solution.

The bottom line is that it is the merchant’s responsibility to ask vendors the right questions and weed out non-PCI compliant solutions.  The card brands and the PCI SSC are not in the business of regulating vendors, they leave that to the marketplace.

If you are looking for a PCI compliant mobile payment solution, talk to Verifone, Equinox, Ingenico or other recognized card terminal manufacturers as those are going to be your only PCI certified mobile payment processing options at this time.

UPDATE: I have had a number of people contact me about the certification status of the Square solution based on the fact that Square Inc. is listed on Visa USA’s Web site as a PCI DSS compliant service provider.  Remember, this listing only means that the card processing services provided by Square Inc. to their customers (i.e., all of the back office processing they do to process card transactions) are PCI DSS compliant, not that the devices that actually conduct the card swipe are certified PCI compliant.  A certified card terminal would be PCI PTS certified and the software running on the terminal would be PA-DSS certified.  The Square Inc. device that connects to iPhones and Android devices does not have that PCI PTS or PA-DSS certifications, therefore it should not be used for conducting credit card transactions.

UPDATE: Here is another solution that avoids the iPad altogether, Hubworks Interactive.  I spoke with them and their QSA and this product avoids the iPad by conducting the transaction in the digital framework surrounding the iPad.  The iPad is strictly used as a display and a Wi-Fi conduit.  The digital framework encrypts the cardholder data before it is ever seen by the iPad just as Mark Bower suggested would work.

UPDATE: July 25, 2012 – In the July issue of Transaction Trends, page 6, there is an announcement from Square that they are offering a new loyalty program for merchants using Square Register and Pay. Let us hope it is securely implemented as I am sure Square is using a customer’s PAN for tracking based on how they describe the program.

UPDATE: August 30, 2012 – The Square Web site is now implying that the transmission of card data is secured through “industry-standard encryption,” whatever that means.  There have been rumors that Square has implemented point-to-point encryption (P2PE) in their card readers but was not advertising that fact.  That is why I went to this page to see what, if anything, had changed.  However, based on the statements on this page, it appears that P2PE has not been implemented as you would think they would be touting that fact.

UPDATE: October 15, 2012 – A good friend of mine just started working at Square, so hopefully we can get to the bottom of how Square works and what risk there is to merchants using their solution.  Stay tuned.

More On Mobile Payments

As I have found out, the definition of “mobile payment” is defined by to whom you are talking.  For consumers, mobile payment means using their smartphone to pay for goods and services.  For merchants it includes the consumer definition as well as using smartphones or similar mobile devices to process payments.

Last year I wrote a post regarding mobile payments and the use of smartphones, primarily the iPhone, for use as credit card terminals.  When I wrote that first post, Apple was running an advertisement for the iPhone that showed it being used to process a credit card payment with the ubiquitous tag line, “There’s an app for that.”  Shortly after that post, the advertisement dropped the iPhone as a credit card terminal.  I am not aware that the PCI SSC or any of the card brands complained about that advertisement, but I found it interesting that those images of it processing a credit card were removed particularly given that a number of security and privacy issues that were and still are being discussed regarding the iPhone.

That is not to say that iPhone credit card adapters have not continued to be developed.  It is just that they are nothing like the one shown in that original Apple advertisement.  The first one that I came into contact with was Verifone’s PAYware Mobile solution and the fact that it is PA-DSS certified.  Whoa!  In my previous post I talked about all of the issues with the iPhone that make it almost impossible to be PCI certified.  How did Verifone create a PA-DSS certified application on the iPhone?  What Verifone did was to create a digital back to the iPhone.  All of the operations that need to comply with the various PCI standards are done through the digital back, not the iPhone.  The iPhone is just used as a display.  In the event that a credit card will not swipe through the digital back, the customer must go to a standard register.  I have also been privy to a number of similar iPhone applications.  All of them avoid the iOS interfaces as iOS is the problem in achieving PCI compliance.

While iPhone is the “Big Kahuna” of smartphones, it does not mean that Android and Windows Phone devices are not also used for credit card payments.  Unfortunately like the iPhone, Android and Windows Phone devices have similar issues that make them difficult, if not impossible; to have PA-DSS certified applications.  So from a merchant perspective, iPhone, Android and Windows Phone all have to be treated very carefully when they are used to process credit card payments.

But security concerns have not stopped merchants from rolling out mobile payments.  Starbucks recently introduced an iPhone and Android application that allows the customer to put their Starbucks cash card on their phone.  The application creates a 2D bar code with the cash card’s number.  The Starbucks POS system reads the bar code and automatically deducts the purchase from the account’s balance.  Within a week of releasing the application, it was determined that if you take a picture of the screen containing the bar code, anyone with the bar code can use the account until it cannot pay for a purchase.  So much for secure mobile payments.

If we expect to secure payments, the traditional credit card is just not going to get the job done.  EMV, aka Chip and PIN, is a short term technological fix but also a back up payment method for where I think we are really headed.  I truly believe that the future in payments is smartphones and other mobile devices with software that generate one-time transaction codes for paying for goods and services.  Whether those codes are displayed as a 15/16-digit number or bar code on a screen or transmitted via Wi-Fi, Bluetooth or RFID, a consumer will not need a traditional credit card.  A 15 or 16 digit number will be necessary to use so that POS systems do not have to be re-engineered to support the new payment method.  Scanners are already capable of reading bar codes from smartphone screens, so that much of the solution is already in place.  Wi-Fi, Bluetooth and RFID technology is coming as we speak so it is only a short matter of time before the infrastructure is in place to support such a solution.  All that is needed is the software.

Such an approach not only will secure card present transactions, but would also tackle the security issues we face with card not present transactions.  If done right, mobile payments can become the solution to our PCI compliance problem.

Extremely Mobile Payment Processing

In a previous post I discussed mobile computing and PCI compliance.  In the last couple of weeks I have been questioned about using mobile devices such as smartphones and Wi-Fi enabled PDAs as payment terminals and I thought this particular incarnation of mobile computing deserved an in-depth look.

Pay attention to that Apple iPhone advertisement.  If you notice in one of their advertisements they show a person processing a credit card payment on their iPhone.  As Apple likes to say, “There’s an app for that.”  However, it is not just Apple that has a payment application for a mobile device; there are also payment processing applications for Windows Mobile environments.  There are also proprietary solutions from VeriFone and the like.  Some of these applications are PABP and/or PA-DSS certified.  Devices from VeriFone and the like are PCI PTS certified, but the iPhone and other cellular phones as well as PDAs are not PCI PTS certified devices.

So when the pizza delivery person shows up at your door and wants to swipe your credit card through their mobile device, how do you know that it is safe?  You likely will not know.

The security surrounding the telecommunications used by these devices is the easiest thing to discuss.  All of the devices I have been able to examine use telecommunications methods that are encrypted either by SSL v3 or TLS.  The cellular network and Wi-Fi are just used as the conduit and are not relied upon to provide any security.

Do not assume that VeriFone and the like are meeting all of the PCI standards.  While their mobile payment terminals are PCI PTS certified, the application software in those devices is not PA-DSS certified.  I pointed to the flaws in these devices in a previous post.

But there are bigger problems lurking with the iPhone.  Ask any computer forensic examiner about the iPhone and they will talk at length about the fact that the iPhone has a number of “features” that make security and privacy things of the past.  From a PCI compliance perspective, some of the more problematic issues are as follows.

• Deleted information does not physically get deleted.  In some cases, deleted data can remain on an iPhone for up to six months or even more depending on use.
• The iPhone has a built-in keyboard logger, so anything typed into it is recorded.
• While it is not certain that card swipes would be retained on the iPhone, given all of the other information it retains, it is highly likely that such information would also be retained.

As a result, using the iPhone as a payment processing platform is probably not a good idea until it is certified.

So what, if anything, are the PCI SSC and/or the card brands doing about this situation?  As much as they can, given that these solutions are popping up faster than they can identify them.  The problem is that the developers of these applications are usually unaware that they are required to comply with various PCI standards.  And since the developer is responsible for certifying their solution unless they get ‘ratted out’, the solution will not get certified.  So it is up to the application developer and the merchants to ensure that an application is properly certified.  If that is not worrisome enough, the cost involved in certifying such an application would likely raise the cost of that solution to a point where it would not be economical to the merchant or salesperson.

Dispelling Rumors – CVV/CVC

One of the things I hate about blogs is that they seem to generate more rumors than dispel. One of the reasons I created this blog was to get rid of some of the rumors surrounding the PCI process. Where these rumors come from, I’m not sure. However, the sooner they are dispelled, the more secure we will be.

The rumors I would like to dispel in this posting are related to why merchants seem to think they need to retain the card verification value or code otherwise known as CVV/CVC. It’s that three digit code on the backs of Visa or MasterCard cards and four digit value on the front of American Express cards. Actually, to be correct, American Express calls it the CID. Regardless of what it’s called, it is NOT allowed to be retained once a transaction has been processed.

The first rumor is that by using the CVV/CVC in transactions merchants reduce their interchange fees with their processor and the card brands. This is not true.

What is true is that by including the CVV/CVC value when a merchant submits a transaction for authorization, should a dispute or chargeback situation arise, the processor and/or card brands will reduce their fees on the dispute or chargeback. The rationale being that the processors and card brands assume that by having the CVV/CVC, it is less likely that the transaction will result in a dispute or chargeback.

The second rumor is that merchants conducting repeat transactions need to submit the CVV/CVC for the original and all subsequent transactions. Again, this is false.

There are two ways to conduct such recurring transactions. The easiest way is to use a processor that can provide you with a reference number from the original transaction and then process all subsequent transactions by allowing you to use the reference number so that your organization does not have to store the cardholder information. The other option is for your organization to store the cardholder’s name, account number and expiration date. Of course, if your organization is storing this information, you need to ensure it is stored securely either by encrypting it if on a computer or physically securing it if using a manual system.