4

I need to store masked PAN with first six digits and last four digits along with the card expiry month and year. Is it safe to do it according to the PCI rules?

Regarding four digits has been previously discussed in the following post.

Minimum Requirements For Storing Last Four Digits

It mentions that storing first six digits and last four digits is ok with PCI compliance. Is there a official PCI documentation with this information?

I referred to pci_dss_v2 and pci_fs_data_storage, but could not find an answer.

3.3 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed).

The rule most are referring is the 3.3 requirement. But this only applies if I am displaying the PAN, but it does not mention anything about storing first six + mask + last 4 digits. Appreciate any help...

  • 1
    Note, not that it affects your question, however the latest version of the PCI DSS standard is 3.1, not v2. – SilverlightFox Mar 10 '16 at 10:26
  • From your comments it sounds like you're asking the wrong question. Imho you should be asking how you can reduce your PCI scope or even who is responsible for PCI compliance (given you seem to be doing this work for a client). Pragmatically if what you're concerned with is styling there are other options, check out an iframe service like the one offered by Braintree (if you have a choice of payment processor) or Spreedly (for a wide but potentially expensive choice). Using those services you might get away with SAQ A, which is better for everyone really. – Richard Mar 14 '16 at 20:03
  • Hi Richard, in my case I don't have options to select a payment gateway as it's been already selected. I tried the Iframe option (created a fully functional prototype as well), but the UI modifications are limited and my client wants to have complete control over UI changes. Thanks for your suggestions though. – Dhanuka777 Mar 14 '16 at 22:18
2

Considering your questions indicate you are already processing card holder data, either by transfering PANs or storing (partial) PANs, you fall in the category of SAQ-D. So this means you should be already undergoing PCI audits (provided you have over 300k transactions annually), so best is to check with your QSA and see what they say.

  • Thanks, what do you mean by "processing", is it relating the masking the data and store? Can you give me a reference to this?. Would it be ok if I just store last 4 digits and expiry, will it also go under the same rule. – Dhanuka777 Mar 8 '16 at 2:19
  • @Dhanuka777 the moment you accept a card number and it is sent to your machines, it's considered processing, even if you do not store it and just pass it onto another service provider like a payment gateway, it's still considered processing as it resides at some point in your volatile memory. – Lucas Kauffman Mar 8 '16 at 2:22
  • Lucas, one more thing "...you should be already undergoing PCI audits". My app is still in development stage. Do I have to get this audited by someone since I am "processing" credit card? – Dhanuka777 Mar 8 '16 at 2:27
  • 1
    Yes, after your development, before you start accepting real cards, you are required to get your full solution and network environment audited by a QSA. This is far from cheap. If this is just a small part of your application, it might be better to integrate a third party payment gateway that avoids you touching the card. – Lucas Kauffman Mar 8 '16 at 2:31
  • Thanks Lucas, this is very helpful. I am using Authorize.Net, even if I do not store card details, do I have to go through the audit for SAQ-D? – Dhanuka777 Mar 8 '16 at 2:44
1

The first 6 digits are not extremely sensitive information. They comprise the IIN or Issuer Identification Number (https://en.wikipedia.org/wiki/Bank_card_number). The last four digits are also not considered sensitive information. In fact the first six and last four are the maximum number of digits that are allowed to be displayed (see PCI DSS 3.3 https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf All other PCI number references come from this document).

However the EXP Date + PAN IS considered sensitive information. Page 2 of this document has a nice explanation of storage procedures (https://www.pcisecuritystandards.org/pdfs/pci_fs_data_storage.pdf).

In addition 3.4 applies in this case. You have rendered the number unusable through truncation (although the Luhn Checksum allows for the number to be guessable). However you must protect the EXP Date and it is recommended (note that it does not appear to be required) to not store the truncated PAN in plan text but to stack protection with one way hashing or encryption.

  • In my case I am not storing PAN. "EXP Date + PAN" is not going to be stored. It's the first six digits + last four digits (not all digits) with expiry. Isn't that safe to do it? – Dhanuka777 Mar 8 '16 at 2:21
  • In the page 2 (fs_data_storage), it says, " Be sure to mask PAN whenever it is displayed. The first six and last four digits are the maximum number of digits that may be displayed.". What if you only store the masked number, is that allowed? – Dhanuka777 Mar 8 '16 at 2:23
  • @Dhanuka777 That would be "Truncation" under 3.4, however you must protect the EXP Date see my second link. – AstroDan Mar 8 '16 at 2:26
1

I you mixed the meaning of the different requirements and have a certain confusion.

Requirements 3.3 "Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed)." talks about display not storage ! if you mask the PAN it provides a solution for this requirement.

Requirements 3.4 3.4 Render PAN unreadable anywhere it is stored ..." talks about storage not display !

You wrote "I need to store masked PAN" masked PAN is related with Requirement 3.3. and storage is related with requirement 3.4 to fulfill this requirement you can use one way hash / truncation / cryptography / token

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.