21

Possible Duplicates:

  1. Best practices for taking and storing credit card information with PHP
  2. Storing credit card details
  3. Storing Credit Card Information

I need to store credit card numbers within an e-commerce site. I don't intend on storing the whole credit card number, as this would be highly risky. I would like to store at least the first five digits so I can later identify the financial institution that issued the card. Ideally, I would like to store as much of the credit number as I safely can, to aid any future cross-referencing etc.

How many digits, and which particular digits, can I safely store?

For example, I imagine this would not be safe enough:

5555 5555 555* 4444

Because you could calculate the missing digit.

Similarly, this would be safe, but not be as useful:

5555 5*** **** ****

Is there a well accepted pattern for storing partial credit numbers?

jww
  • 97,681
  • 90
  • 411
  • 885
Joel
  • 11,431
  • 17
  • 62
  • 72

7 Answers7

40

The Payment Card Data Security Standard states that if you are handling cardholder data, then you are subject to the constraints of the PCI DSS (which is very comprehensive and a challenge to comply with). If you want to store part of a card number, and don't want to have to deal with the Standard, then you need to make sure that a) you store NO MORE THAN the first 6 and last 4 digits; b) you don't ever store, process or transmit more than this. That means that the truncation has to be carried out before the data enters your control.

Given that you are talking about an ecommerce site, I think you'll have to deal with the PCI DSS sooner or later (since if you're not taking full PANs, you can't process transactions). Realistically, then, you should avoid storing more than the first 6 and last 4 digits of a PAN; the Standard then does not 'care' about this data, and you can store it in whatever form you see fit. If you store, say, the first 7 digits, then Requirement 3 of the Standard kicks in (and you start having to really understand key management in encryption).

I hope that this is of use.

sanmai
  • 29,083
  • 12
  • 64
  • 76
  • 2
    Anyone have any actual references for this? e.g. "the Standard then does not 'care' about this data" ... – Kzqai May 01 '12 at 02:02
  • 1
    BK is correct - here is the official PCI answer: http://selfservice.kb.net/article.aspx?article=9488&p=81 – chrishiestand Aug 28 '12 at 18:41
  • @chrishiestand, seems that the link is expired, it should be great if you have a way to find that answer again... – T30 May 24 '17 at 13:26
5

March 2013 Edit:
A very pertinent resource is the PCI Security Standards Council, an organisation founded in 2006 by five of the biggest global Credit Card brands (AmEx, Visa, MasterCard, JCB International and Discovery) and which is the de facto authority on Security matters for the Payment Card Industry (PCI).
This organization publishes in particular the PCI Data Security Standard, currently in its version 2.0 edition which covers issues such as the management of complete or partial credit card numbers. This document if freely available but requires a simple registration and acknowledgment of license terms.

The following is the original, c. 2009 answer, mostly correct but apocryphal.
A common practice (whether legal or not I do not know) is to store the last 4 digits, as this may be used to help the customer confirm which of his/her credit cards were used for a particular transaction.

Without significantly improving the odds of a malicious person guessing the complete number, one can store the first 4 digits which are representative of the financial institution which issued the card, as mentioned in the question.

Do NOT, save many more digits than these 8 digits because otherwise, given the LUHN-10 checksum, you may provide enough info to make guessing the complete number more plausible (if still relatively hard, even with insight from the series used by a given issuer, in a given time period, but one should be careful...)

To make this whole thing safer, technically and legally, you may consider only storing such info if the customer explicitly allows it. You should also consider masking this info with a simple hash for storing in the database.

Also, what you can / should store following a particular transaction, is the transaction ID supplied by the Credit Card Processor, at the time the transacton is submitted. This ID is the key that allows locating most (all?) of the info you would even need, would there be any issue with a particular transaction. This type of info can typically be queried from a secure web site maintained by the Processing company, along with some aggregate reports which may include a grouping by card-type (Amex, Visa...) if that is why you are thinking of storing the first four.

mjv
  • 73,152
  • 14
  • 113
  • 156
3

If you don't need to store the whole credit card number, why do you need to store it at all? If you want to save the financial institution that issued the card, why don't you store the financial institution that issued the card?

mob
  • 117,087
  • 18
  • 149
  • 283
  • 4
    As a user, it is useful for me to see what card is being used for a particular transaction. I can tell if a site is still using my old number on a card that was lost and cancelled, or if it is using my new card. – Lance Fisher May 07 '12 at 22:32
2

Your specific question is answered in sec 3.3 of the PCI/DSS document. First six and last four are max for display. Customer (paper?) receipts are more restrictive. Those with a legitimiate need to know can see full card data.

My recommendation is to contact your merchant provider and see what options are available to you. A number of the modern transaction gateways have "vault" features where sensitive information is stored at the provider and you simply reference customers by a token number when you want to bill them or check account information.

Along the same lines use of transaction specific tokens can be used to reference needed data stored on the providers system.

However I can't stress enough the importance of reading and understanding PCI DSS. Simply punting secure storage does not magically obsolve you from being subject to PCI compliance requirements!! This is only possible when your system never touches full card data.

Einstein
  • 4,450
  • 1
  • 23
  • 20
  • 3
    "Reading and understanding PCI DSS." Yeah good luck with that. :) In all honesty as soon as credit card companies start strictly enforcing this every developer is going to need access to an expert, probably in a legal capacity, to make sure their software and hardware complies with the standards. It definitely wasn't written for the average computer programmer to understand. – Jordan Reiter Aug 12 '11 at 20:52
1

The accepted pattern is don't store them at all.

In certain jurisdictions you may be breaking the law by storing them or any part of them.

You could instead, store a one-way (and therefore unrecoverable) hash of the credit card number.

Mitch Wheat
  • 295,962
  • 43
  • 465
  • 541
  • The one-way hash is not a bad idea. It will allow me to identify if two credit card numbers were the same. Thanks for the idea! I would like to still store a partial number also, however. But, maybe the first five digits as well as a hash would be enough.. – Joel Sep 28 '09 at 04:46
  • 13
    I disagree on all points. Storage of card data is not illegal. Requirements for secure storage and processing are governed by the card industry. The PCI/DSS requirements are available online and apply to you whether you store the data or not!! Use of a hash algorithm alone in this case is generally exceeding dangerous given low entropy of card numbers and covering block size recovery of origional number would be quite easy to accomplish using precomputed tables and other brute force techniques. – Einstein Sep 28 '09 at 05:07
  • You could add a static salt value could make it a bit harder to brute force. But I think you're right. I'll have to rethink this. If the hash space were smaller than the number of credit cards this could prevent the brute force problem, but then it is less useful because different cards could have the same hash. Maybe I'll drop the hash idea. – Joel Sep 28 '09 at 05:16
  • Disregard the sentence about reducing the hash space. That doesn't solve anything. – Joel Sep 28 '09 at 05:19
  • 16-digit card number 111,222,333,444,555 (trillions) -- 15 digits subtracting check bit -- first two-four digits are limited to about a dozen possibilities. subtract another 2-4 digits. This leaves at most 11 to 13 digits of entropy. Which works out to less than 1 trillion checks. This is nothing for a modern computer. Use of salts does nothing. – Einstein Sep 28 '09 at 05:23
  • @Einstein: I stand by my comment that best practice is not to store card numbers – Mitch Wheat Sep 28 '09 at 06:09
  • 9
    I disagree. There are valid reasons to store card data and just saying don't do it does not answer the specific question Joel asked. – Einstein Sep 28 '09 at 06:40
  • The valid reasons being? Storing them makes it possible that they can be stolen. – Mitch Wheat Sep 28 '09 at 06:51
  • 3
    Subscription services where customers are billed automatically on a recurring basis. E-commerce sites which give users convinent funding options. Many respected systems (PayPal..et al) store card data. Your obviously correct however it is possible to mitigate such risks -- not storing them is NO EXCUSE to not have a secure system in the first instance. An attacker could just as easily tap the transactions and "store" them in their own database. – Einstein Sep 28 '09 at 17:46
  • @ Einstein: yes, and let's not forget the incident where PayPal had thousands of credit card details 'leaked'... – Mitch Wheat Sep 28 '09 at 23:43
  • @Einstein: Also, when your application transmits credit card details 'over the wire' it should be doing so using SSL (i.e securely encrypted). Would you like to explain how an attcker 'taps' these transactions. If this is broken, then so is all of e-commerce. – Mitch Wheat Sep 28 '09 at 23:49
  • 1
    I'm sure others are much more qualified to draw a complete threat tree for you. This can occurs by compromising the ecommerce server and installing necessary software. I don't disagree with your sentiment but we must all live within the context of our time. IMHO ideal solution is to replace the current 'take' model with a 'give' system where the user initiates transfer of funds (Essentially PayPal).. Rather than merchants taking funds from the customer. – Einstein Sep 29 '09 at 09:38
  • @Einstein: " This can occurs by compromising the ecommerce server and installing necessary software" - if that has already happened then all bets are off. – Mitch Wheat Sep 29 '09 at 11:09
1

The credit card companies have a standard for this. You'll probably find it buried somewhere in the terms of service of your payment processor that you will obey this standard. It answers you questions. You can find the standard here

tzs
  • 234
  • 2
  • 4
0

Here in Canada, the usual way is to store the first 4 digit ( to identify the financial institution) and the 4 last digit to identify the credit card.

But be sure that you didn't break any laws.

Nettogrof
  • 2,116
  • 2
  • 15
  • 22