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

You are right, using sessions is very insecure for storing sensitive data, there are ways to break into sessions with what is know as:

Session hijacking
Session fixation

The most secure way that comes to my mind is that store the info in database (for temporary time) and then read that value on the page where you need it. Once you are finished doing it all, you can delete it back.

Note that:

• you must encrypt it before saving to database.
• be careful if you are on shared hosting
• make sure that you delete it back once done with it

You may find this reflectively useful as well :)

Answer 2

It appears that anyway you touch it, you'll need to provide for secure credit card number storage capabilities. If the server is compromised, at any time it will contain enough information to decrypt currently stored credit card numbers (i.e. keys and encrypted numbers). Potential solution is to use an internal server that acts as a "encryptor/decryptor" service and nothing else. This way compromising one machine does not expose credit card numbers.

Answer 3

There is another way, but it requires Ajax. No storing of credit card numbers AND a review page.

Page 1: Form to capture shipping, billing and credit card information. Ensure that the "body" of the page, including the form, is in a DIV with a unique ID to allow you reference it with JavaScript.

Page 2: A file on the server that will accept a GET/POST request with the form fields in it and return a properly formatted "review" page to your liking.

Checkout process:

1. Validate form.
2. Copy credit card related fields into global JavaScript variables.
3. Loop through form fields and build a query/data string with the form fields (excluding credit card related fields)
4. Do an Ajax request to the "review" page, passing the query string of form field/values with it. Render on server and return to calling Ajax function.
5. Take rendered HTML review page returned from Ajax request and replace content in your "DIV" container with it (effectively replacing the form and other elements with the review HTML).
6. Use JavaScript to copy the credit card data stored in global JS variables into the appropriate place on the review page. You may also copy the card data to hidden form fields to submit when the user "completes" the order from the "review" page.
7. User submits order from review page to server, performing card validation with the processor's gateway and then either placing the order, or returning to error handling page, never having stored the card details.
8. I would recommend that the "place order" function perform a full HTTP request (rather than Ajax) in order to reload the browser with a page that no longer has the card data stored in global JS variables.

It's a bit of a hack, but when done properly, it's 100% seamless to the user and allows you a single transmission of the card data with no need to assume risks with temp DB storing, etc.

Answer 4

You could store a hash of the card nr in session and the same hash and the actual number and the user's session id in a database. Then for each page you can check the hash and the session info to get the card nr.

Answer 5

There is no need for sessions or the database to hold the information.

Every page is a form that posts the data. On each subsequent page the post variables from the previous page are added to hidden form fields so that the next form submission posts the data again. This way nothing is ever stored, but the information is carried from page to page. This also forces the user to complete the process from start to finish without attempting to skip steps.

As long as the form is submitted over HTTPS, the data is encrypted automatically and the security burden is on your SSL certificate provider.

Many popular commerce sites implement this. For example OSCommerce.

Answer 6

Consider modifying your checkout process to get rid of the necessity of storing credit card information.

Page 1: User enters non-credit-card order information, like shipping and billing address
Page 2: User verifies non-credit-card order information, enters credit card information, and clicks "Pay Now" (or "Revise Order" if they want to change things)
Step 3: Info is submitted via a $_POST request to an SSL page, which completes serverside checks, submits credit card data to processor, and directs the user to a success or error page based on the response.

This way you'll avoid a haze of technical problems and compliance problems. Storing credit card data in a database or cookie, even for a short period of time, even if encrypted, WILL mean that you're responsible for a higher level of PCI compliance. The only tradeoff is you won't be able to show a "review order" page with credit card details. And how big a tradeoff is that, given that your "review order" page can't even show the full credit card number?