tags:

views:

879

answers:

7

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?

+2  A: 

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
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
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
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
Disregard the sentence about reducing the hash space. That doesn't solve anything.
Joel
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
@Einstein: I stand by my comment that best practice is not to store card numbers
Mitch Wheat
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
The valid reasons being? Storing them makes it possible that they can be stolen.
Mitch Wheat
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
@ Einstein: yes, and let's not forget the incident where PayPal had thousands of credit card details 'leaked'...
Mitch Wheat
@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
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
@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
would the downvoter please leave a comment. Thanks.
Mitch Wheat
+3  A: 

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?

mobrule
A: 

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
+1  A: 

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
+2  A: 

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
+8  A: 

Hi,

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.

Cheers,

B

+1  A: 

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

related questions