database question

[keny]

hello,

 

I'm setting up my osc app, and was wandering through the database and I noticed that in the orders table, the credit card information for every purchase is being stored. My question is:

 

1. why must we store credit card numbers in the database to begin with

 

2. how can I be sure this feature is hacker safe

 

3. how can I disable the storing of the cc numbers.

 

In an attempt to answer my own question, would it be that we need the information should we have to do a return? if that's the case, I'd rather do it from my gateway's website as opposed to through osc.

 

The ip, login and password to the database is stored in a php file in an unprotected directory. Shouldn't there be some sort of encryption method to store this information on the server?

 

Continuing the conversation, if I did want to store credit cards on there for stuff like future purchases, I would want to *not be liable* for the theft of the customers private info, so in the event that something like that did happen, what sort of terms and conditions could exempt me from that liability?

 

i don't intend to show off the weaknesses of the application, I am looking to understand how the programs deal with those potential issues. And also perhaps a modification that would disable the long-term storage of credit card information in the database.

 

keny

[kirikintha]

Do not store CC's period. you should not have a cc number anywhere in your store. If it is storing them - disable it. I use a payment gateway, simple safe secure.

[keny]

Perhaps it is storing the information, because I have the program set up in test mode?

 

I haven't used my real authorize.net account, it seems as this is default behavior.

[kirikintha]

quite possibly - it also may just be the form of payment you are using to test - I use a developer account from authorize.net to test with.

[spax]

Do you have the credit card module enabled in your admin? If so, disable it.

[keny]

ok i'll read up on those modules. right now it appears that the credit card and payquake modules are up and running and the authorize.net one is not.

 

i wonder if you can have a test account on authorize.net at the same time as a live one. I already have a script that I use to do transactions through them that is live. I just didn't want to have to take that down to get something else up and running....

 

thanks, ill get back after i figure that out. there is still a lot of other information being stored in that table that i wonder how such a change will affect. I'm writing a consignment agreement-like script where users can monitor the sales of their products.

[cvnieman]

I noticed my Live site is storing CC# as well if you go look at the order information. Im using AIM with Authorize.net.

[keny]

so i was looking through the code and i found a segment where it's probably the program adding the cc information to the database, and It is not the credit card module, it is checkout_process.php at lines 57 through 96. check it out....

 

i'm wondering if altering the CC number around line 56 to XXXXXXXXXXX1234 would do the trick in this situation. Or perhaps a seperate utility that goes into the database and kills all the existing cc numbers.

 

perhaps something like this at line 56:

 

adapted from oreilly php cookbook, chapter 1.3.3:

 

substr_replace($order->info['cc_number'],'xxxx ',0,strlen($order->info['cc_number'])-4);

[jasonabc]

Im using AIM with Authorize.net.

The A.net AIM contribution unfortunately sends unencrypted, plain text credit card numbers straight into the orders database table. This will be addressed in a future release. I released a patch available on the AIM contributions page which replaces the middle digits with XXXX's before the string is inserted into the database.