Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Credit Card Database Security


bopper

Recommended Posts

I have searched these forums for some dialog on this issue. Have read a lot on the credit card module and how the number is split up for that, part in the db and part sent by email. But the problem I see is that in the orders table there are all the cc numbers for payment made using one of the gateway modules...if someone should hack the db or get a sql dump there they are with all pertinent info. Is there any solution that folks are using to secure this information? Sorry if this has been hashed out before, I could not find it.

bopp

Link to comment
Share on other sites

If you are storing customers credit card details you must have your website IP based with a full SSL, and with the whole of your 'admin' folder Password Protected and secured behind that SSL. I wouldn't buy off you if you didn't have a full SSL on your site.

 

Vger

Link to comment
Share on other sites

I have searched these forums for some dialog on this issue. Have read a lot on the credit card module and how the number is split up for that, part in the db and part sent by email. But the problem I see is that in the orders table there are all the cc numbers for payment made using one of the gateway modules...if someone should hack the db or get a sql dump there they are with all pertinent info. Is there any solution that folks are using to secure this information? Sorry if this has been hashed out before, I could not find it.

bopp

 

When I first installed Linkpoint it was storing entire credit card numbers in the db, yikes! A later module update took care of that--now it correctly splits the numbers between email and the db... For my earlier orders, I ended up editing the numbers in the database manually, pulling the middle digits out and recording them separately. Even got rid of my old database backups. It was a pain in the butt, but I sleep better knowing all that info isn't sitting on my server... If I had to do that over again, I'd probably just get rid of all the past data, not bother splitting and saving.

 

There is also Card Zapper--it works well for deleting credit card data from osC admin. But it doesn't split, it just deletes the entire number for an order.

"Buy the ticket, take the ride..." -HST

Link to comment
Share on other sites

Thanks for the info on the zapper contribution Douglas...I hadn't seen that. Since the catalog doesn't reuse the cc number at any time after an order is finalized it seems one could write a scheduked task sql that would overwrite the cc number after a specified amount of days...there is no reason I can think of to keep those numbers in the db, especially if the transaction has been finalized by one of the gateway modules such as authorize.net

Link to comment
Share on other sites

The reason we keep them is in case of chargebacks--even our Linkpoint gateway doesn't store the full numbers, so we need to keep them ourselves. But it's true that at some point there is no need--not sure exactly how long that is.

"Buy the ticket, take the ride..." -HST

Link to comment
Share on other sites

This page http://www.sitepoint.com/forums/showthread...t=102898&page=6

had a discussion about it, basically using a combination of md5 hashes and the PHP mcrypt function(s) ( http://www.php.net/mcrypt ). Since not all hosting companies compile in mcrypt libraries somebody did it in pure PHP: http://www.yan.cz/brutuslib/

Link to comment
Share on other sites

Anyone able to see it can simply decrypt it otherwise you wouldnt be able to see it yourself.
Sure, it is not the strongest defense, since you will have to keep the password with which the server encrypts the cc number in a file somewhere. That means that the hacker who gets hold of your database backup or gets access to the SQL server will have to gain access to the code too, to find the password. Say that it only frustrates 9 out of 10 hack attempts, it is still another layer of defence.

 

Of course deleting the cc number from the database when you no longer need to keep it stored on the webserver is the best option. Till that time adding another layer of obfuscation certainly won't hurt IMHO.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...