2

I have an application where I take the user to a PCI compliant payment gateway for completing the payment. I want to give the functionality of "Remember my card" so that the user does not have to enter the details again in the future. I am thinking of storing the card data on the user's device itself (encrypted and not hashed because I would need to reverse it to the actual card number as required by the payment gateway). The CVV would not be stored.

Is storing the data on the user's device that in most cases would be used by the user only, a violation of acceptable security standards? If yes, then what are the levels of PCI DSS/PA DSS compliance requirement here?

Anders
  • 64,406
  • 24
  • 178
  • 215
Rahul Nanwani
  • 129
  • 1
  • Investigate whether your payment gateway provides a "card tokenisation" service, where provided card details are processed by the gateway and a token is returned, allowing the details to be stored on a secured system, and referenced from the (presumed insecure) client system. See https://en.wikipedia.org/wiki/Tokenization_(data_security) for some details – Matthew Jun 08 '16 at 14:36
  • There are a lot of gateways possible (since the gateway is decided by the intermediate website implementing it) and no they don't support tokenisation. – Rahul Nanwani Jun 08 '16 at 14:58
  • You would have to consult with a QSA for a definitive answer, but http://security.stackexchange.com/questions/59520/how-to-store-credit-card-information-for-repeated-transactions-and-still-be-pci covers a lot of the issues. I would advise against storing the number on the device though, even in encrypted form - by definition, the decryption key must also be stored on the device (or sent to the device), leaving it vulnerable. – Matthew Jun 08 '16 at 15:07
  • @Matthew not by definition - an app could store an encrypted blob and submit that in lieu of the plaintext credit card number, and the server receiving the submission holds the necessary key to decrypt, use, and then forget. However that's a lot of work compared to the normal ways of doing it... If the OP is trying to shim to make up for limited feature gateways, they're just going to put themselves in the scope those gateways are designed to protect them from. – gowenfawr Jun 08 '16 at 15:44
  • @gowenfawr That would essentially be poor-man's tokenisation, and the receiving server would need to know how to decrypt - if the receiving server is the gateway, it doesn't help. If the app sends data to a developer controlled server, then to gateway, it wouldn't need to store on the device, since it could implement proper tokenisation on the server. – Matthew Jun 08 '16 at 15:49
  • @Matthew we agree (poor-man, wouldn't help) I'm just saying it's possible to design something that _didn't_ leave encrypted blob _and_ key on the client app. – gowenfawr Jun 08 '16 at 15:50
  • Storing card data on a user's device ? Given the vast number of security ignorant people who under their own stupidity manage to get repeatedly infected by malware, I'm not sure storing card details on their devices is sensible idea ! – Little Code Jun 08 '16 at 16:19
  • If I didn't leave the data on the app, and took it to one of my servers to encrypt it, then it obviously comes under the PCI compliance guidelines. The point is can this be done without undergoing PCI compliance checks or by meeting the SAQ - A standards only? – Rahul Nanwani Jun 09 '16 at 05:22

1 Answers1

2

PCI-DSS rules generally require that any PAN stored be encrypted in such a way that it requires not one, but two authenticators to decrypt.

In practice, this would normally mean that even if you intend that the end-user is the only one with an encrypted copy, this would be insufficient from a regulatory standpoint. "Who" has a copy is irrelevant, in this respect. If decryption can be accomplished by a single key from the provider (i.e., you), and you cannot affirm that the device it's stored on is encrypted (that is, a client responding with a true/false about the filesystem encryption following a transaction request is not currently a capability of any mobile device I'm aware of), then you will have no way to declare the end-user devices out-of-scope during a PCI audit.

One scenario might work: if you have an application which generates and secures its own key for storing the card information, and which then can respond to your server-side payment application with a token for previously-used cards at that site, then you can (probably) satisfy the basic requirements. As long as the server-side application can satisfactorily store and retrieve the PAN upon presentment of a reference token during the transaction, you're fine. However, even in that case the CVC or CVV must be manually provided by the user— that is explicitly not allowed to be stored together with the PAN.

Having the end user store their own card may also possible, but no program or application can be allowed to request that data from the end-user and expect to receive the response automatically, unless you store a unique key for that user server-side for decryption of the PAN. This is why the current strategy is for Android and Apple to store "card details" and autofill fields when they recognize a request to fill out transaction data. That should be fine, but a pedantic auditor could easily demand that you have some way of confirming the end-user's device only works with an encrypted filesystem.

Long story short: you effectively just want a page whereby someone's mobile browser can work with "autofill" in a friendly way. You'll get the same results, without having to worry about additional PCI PAN storage limitations.

Ryder
  • 271
  • 1
  • 8