Securely Storing Credit Card Details

[Lord_Webby]

I am Looking for advice on how to store credit card details securely.

I am about to develop a new website (details being finalized). The project consists of a website that requires a users credit card details to be stored to a database. Unfortunately there is no way around this (I tried to advise against storing the details - but this is a mandatory part of the business). The site requires mysql and php.

So far I have the following:

- use an ssl-ev certificate on the webserver (xampp)
- store the mysql database on another server (also xampp) and restrict permissions depending on the action taking place.
- use 256bit php encryption, and hashing for passing variables and clean mysql data (mysql_real_escape_string) before submitting it to the database.

Does anyone have any other/more ideas on how to ensure security on the above - or perhaps a different process?
Have I missed anything?

(The site is a public site and the owners want to stay away fro the username password route for clients).

[sven1977]

Yes, you forgot something very important.

Apart from sending the data securely from php to the mysql server, you should store the data in an encrypted fashion in the DB. Otherwise, if someone gets access to the DB, the data is right there in user-friendly text format :(

[Lord Majestic]

sven is right - the stuff needs to be kept encrypted in the database - you need to checkout mysql crypto features. Another issue however would be the fact that you'd need to store somewhere crypto keys and you therefore can't really have plain text PHP files with keys stored in them.

It's all a major hassle to deal with credit cards, much better to "outsource" it to Paypal, most users would probably convert better when they see well known payment provider rather than small lesser known site that wants their credit card.

[edited by: Lord_Majestic at 5:41 pm (utc) on Aug. 6, 2008]

[Demaestro]

Yes I mirror Majestic's advise.

I was going to mention it before but I saw you already tried talking them out of it.

Honestly, you can encrypt all day and all it takes is one dishonest employee, or unscrupulous cleaning crew member, or even an ignorant user that invites a virus onto your network to undo all your efforts.

[rocknbil]

Welcome aboard Lord_Webby.

Is your website and host PCI compliant [pubcon.com]?

This should be your FIRST stop. Have your clients read their contract: if they are using an in-store terminal to process CC info, their contract will explicitly disallow collection of credit card orders by any other means than card present or phone orders. Internet orders are a completely different contract with different fee structures.

Merchant accounts that allow collection and processing of credit cards via the numbers you describe will DEMAND PCI compliance. This involves not only your programming but the security of the network and hardware systems on which you do this, see the link above.

This is a BIG DEAL. If caught, the client will have to pay enormous fines and will be liable for all charges in arrears for the time they are operating in an non-PCI compliant environment.

If they forge onward with this, it's your job to make sure they are informed and you need it in a contract waiving you from responsibility - if it all comes down, you'll be the one they try to blame.

Last I'll throw in - I have *NEVER* encountered a project that REQUIRES storage of CC info. Subscription based, recurring billing, account credit and management, whatever the scenario - there is always a way to do it via a reputable credit card processor, which releases you from a PCI compliance audit. If one doesn't have what you need, another will. So there's "always a way" - if the client refuses to see it out of convenience or a tight purse, that is their decision to make. Just make sure you're covered.

Recent discussion [webmasterworld.com]

Another [webmasterworld.com]

[Lord_Webby]

The system is for a company that claims back credit card charges. Users enter personal information and add credit card details so that the company can claim back the credit card charges. Therefore they need to store the details but users never need to access the system again (hence no login information). I was thinking of only giving the website 'write' permissions. The data can then be accessed internally only - by staff (who Will have to login to access the data). I was going to restrict access to the internal website by only allowing internal IP addresses (192.168.*.*).

I've read that amazon use a seperate server connected via a serial port because it is easy to analyse the data being passed through and check why it is being accessed. Anyone know how you would check the information being passed through the serial port?

I believe the servers will be behind a sonicwall hardware firewall.

I should also add that there are no actual transactions taking place. All transactions are delt with offline. The system just needs to be secure to hold the personal and credit card data.

I have a 256bit encryption alogithm for storing details. I was going to use sourceGuardian or similar to encode the key and php files (probably pre-encrypt the key first as well).

I will read up on PCI compliance thanks.

[aspdaddy]

You should definetely look at the 12 security requirements of PCI DSS if you intend to process payments, its not actually very difficult to comply.

Now if you *store* the CC details you could actually be breaking the law (in the UK), check out the 8 principles of data protection and see if you can still justify storing cc details.

[Lord_Webby]

We arent actually processing any payments. Just storing the credit card number (no other details from the card). We are going to use a PCI compliant host.

Does anyone know how you would use a serial console for checking transmitted data's validity? I've been advised amazon does this.