Credit Card / Database Security

Is there something else I should do?

[ksponline]

Hi,

I need to find out how secure this is before implementing it so I can make any necessary changes. In general, a form collects an individual's name, address, and credit card info. The form resides on a secure server (shared certificate on web host's site). My php script processes and sends the info to a mysql database, and generates a confirmation email to the person submitting the form and to billing. Only the last four digits of the credit card information are transmitted in the confirmation emails.

How secure is the credit card information in the mysql database since it's not encrypted? What steps should I take to protect that credit card information in the database since it has to be available in a readable format for billing? Encrypt/decrypt or?

Also, access to the database is via the same username and password as I use to access cpanel. Should I grant privileges to a separate user in phpmyadmin to access the database? The php db connection script resides outside the root directory.

Thanks for any pointers... I don't want to compromise anyone's credit information but I'm not sure what to do beyond not transmitting it via email.

ksp

[mep00]

Even a unpickable lock is worthless in stopping someone who has access to the key (one of the "advantages" of a broken lock). The problem is if your script needs to read the number on it's own, then it will have access to the PW and anyone who can view your code will be able to read the PW.

So no matter what, you must guard the key. The only addition is if you only need to write on the fly, and not read. The you can manually enter the read PW when needed.

The bottom line is that there is no perfectly secure systems, only thoughs which are good enough. As an analogy, there's the 50lb bicycle rule.

All bicycles weight 50lbs:
A 10lb bicycle needs a 40lb lock;
a 20lb bicycle needs a 30lb lock;
a 30lb bicycle needs a 20lb lock;
a 50lb bicycle doesn't need a lock.

[cashmere]

My two cents - not even close to secure.

Once you are up and running, the concept of security becomes *very* real. Something on a shared server is, to me, insecure. A lot would depend on which shared server. Mine seem to have about a hundred people on them.

Get assistance. I wrote a very secure checkout (I think). It's a lot of work to actually understand this stuff. So my consultant who wanted to do a PGP solution says what I have is overkill. That's what I like. The PGP solution would have been great but I couldn't get PGP or GPG running locally so wrote my own stripped down thing.

Again this is my own opinion only. I don't believe in security by obscurity. Now I'm trying to figure out how to convince surfers that it's secure without a trusted "brand" like a big Verisign symbol. I'm going to post a thread on that ... Any ideas? :) So that's another issue ie think about the advantage of using an established method re: perception.

[martyt]

I wouldn't store credit card numbers in any database unless they are encrypted first. Same goes for expiration date and card verification codes. Especially in a shared SQL database (whether mySQL or SQL Server) - if you're not 100% in control of the database server and the only one who knows the sa password, you should expect that some flunky at your hosting company does know the sa password and might spend time poking around in your database for no good reason.

At least make it harder for the casual hacker.

And get rid of the credit card numbers as soon as you don't need them for anything - for example, right after you authorize the card; after that, all you need is the transaction number to complete the capture.

If you're doing real-time auth and capture in one shot, there's no reason to store the card numbers at all; just make the customer wait while you do the auth and if it fails, bounce them back to the checkout screen until they get it right.

[PhoneGuy]

While doing real-time auth is the best solution for security I would have to caution against that. We have chosen to do the auth when processing the order on the "back-end". The main problem with real-time is that when the CC company is down or lagging you lose the order. When the customer can't figure out why the number s/he entered isn't working you lose the order. When processing the auth later you can call the customer or wait for the CC company to be back up again (not often but does happen).

[ksponline]

Thank you to everyone for your input and suggestions. I know I have a lot to learn in the area of databases and security, and certainly don't want to jeopardize anyone's credit information--now I realize things aren't as secure as I'd hoped.

Kind regards,
ksp