Storing Credit Card Numbers in SESSION - ways around it?

Question

I am well aware of PCI Compliance so don\'t need an earful about storing CC numbers (and especially CVV nums) within our company database during checkout process.

Howev

Answer 1

This is what a database is for. I'm not sure about the legal ramifications here (which vary based on country and region), but one approach would be to encrypt the CC number and store it in the database as soon as you receive it from the user. You may want to store the last 4 digits in a separate field so that you can show it to the user when required. When you need to interact with the card processor on the server, retrieve and decrypt the card number from your database.

Answer 2

Use Tokenization. Its fully PCI DSS complient.

More can be fouhd here, https://www.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf

Answer 3

Store the card details to any persistence medium (database, whatever), but encrypt the card number with a unique and random key that you store in the session. That way if the session is lost, the key is too - which gives you enough time to clean out expired/abandoned data.

Also make sure your sessions are protected from hijacking. There are hardware solutions to this, but a simple in-code way is to tie the session ID to a hash of the first octet of the IP plus the user agent. Not foolproof but it helps.

Edit: The key bits to minimizing your risk is to make sure you get rid of that info as soon as possible. Right after the transaction goes through, delete the record from the database. You also need a rolling job (say every 5 minutes) that deletes any records older than your session timeout (usually 20 minutes). Also, if you are using a database for this very temporary data, make sure it is not on an automated backup system.

Again, this solution is not foolproof and I am not even 100% sure it is compliant with CC security requirements. However, it should require an attacker have total runtime control of your environment to actively decrypt customer CC info, and if a snapshot of your database is compromised (much more likely/common), only one CC can be brute-forced at a time, which is about the best you can hope for.

Answer 4

I know you mentioned you're aware of PCI compliance, but using any of the methods already described (eg persisting the card number to disc anywhere) will fall foul of PCI and mean you have a nightmare of compliance headaches ahead of you. If you really insist on persisting the card number to disc, then you might as well get a PCI auditor in now to help you through the process and offer advice. Ultimately they will need to validate the method you've taken is appropriate.

As an example, a lot of the answers here talk about using encryption. Thats the easy bit. They haven't talked about key management which is significantly harder

I think therefore a better approach would be to submit the card details to the payment gateway as soon as they are collected. A good many of payment gateways will allow you to perform a 'store only' style transaction, which will perform basic validation of card details and store the card number to their (already PCI compliant) server, and return you a token id instead. This method means you DONT store the full card number/cvv2 anywhere on your servers, and PCI compliance becomes a huge amount easier.

Later in the checkout process you use the token id to submit an authorisation and settlement.

PCI allows you to store the first six/last four digits (and expiry date) of the cardnumber in plaintext, so you can safely capture those wherever you're comfortable with so that they can be redisplayed just prior to the final step.

Answer 5

Here's how I plan on doing it - everything over https using ssl of course.

Step 1. User enters CC info and presses the next button. The CC info is immediately saved to the CC processor's DB, not your own DB or you'd break PCI Compliance. The CC is not actually charged this step. But you should recieve some unique ID from the processor identifying the CC info. (store the unique id in your db if you want)

Step 2. On the confirmation page, retrieve the CC info from the CC processor using the unique id they gave you. My processor will only let me retrieve the last 4 numbers of the CC anyway.

Step 3. After they confirm the purchase and press the purchase now button, charge the credit card using the unique id.

Step 4. Redirect to a thank you page containing the invoice/reciept which only has the last 4 digits of the CC (Of course you don't have to display the last 4 of the CC, but I think it's a nice thing to show).

Answer 6

At some point later on in the payment processing (last part of step 3), you'll need to encrypt the CC# (and CVC) to be able to send it to the payment processer (I assume)

Why not do that encryption right when you recieve the information, next to the obfuscation needed for the confirmation page. (this is the last part of step 1)

From now on, only work with this encrypted or obfuscated data, making the CC-company the only one who can actually decrypt the full data.