Hmm... I need to find out myself. I don't know what is the right answer to your question. I'll do some Googling and get back to you if I got an good answer. You should email the people at iPage as they probably could answer your iPage question..
Thanks vger...the store and admin are ssl but the cc data is still unencrypted in the db orders table...to me that is a security problem..
When I first installed Linkpoint it was storing entire credit card numbers in the db, yikes! A later module update took care of thatnow 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 Zapperit works well for deleting credit card data from osC admin. But it doesn't split, it just deletes the entire number for an order..
This post has been edited by.
: 05 November 2004, 00:15..
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..
The reason we keep them is in case of chargebackseven 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 neednot sure exactly how long that is...
Had a discussion about it, basically using a combination of md5 hashes and the PHP mcrypt function(s) (.
). Since not all iPage hosting companies compile in mcrypt libraries somebody did it in pure PHP:.
I dont think encrypting the cc number will do any good. 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...