Last week I wrote an article detailing how to comply with the first two PCI DSS Standards. In this article, I will show what is involved in complying with the two requirements in the “Protect Cardholder Data” standard.

Requirement 3: Protect stored cardholder data
Requirement 4: Encrypt transmission of cardholder data across open, public networks

We have provided a secure network to collect and store our customer’s information. Now, we need to turn our attention to the data itself. To fulfill requirement 3, we need to come up with a policy detailing how we will store card holder data. This sounds easy enough, just make a few decisions and stick with them. However, this is actually a bit more complicated as the PCI-DSS FAQ explains. There are 20 different criteria to meet. While I suggest reading the linked FAQ some highlights are:

• 3.1 Keep cardholder data storage to a minimum.
• 3.2 Do not store sensitive authentication data after authorization (even if encrypted).
• 3.2.3 Do not store the personal identification number (PIN) or the encrypted PIN block.
• 3.3 Mask PAN (Personal Account Number) when displayed (the first six and last four digits are the maximum number of digits to be displayed).

Continue reading…

PCI DSS (Payment Card Industry Data Security Standard) is a security standard that applies to companies handling credit card numbers. The PCI level of enforcement differs based on the volume of transactions that a company handles. The lowest level is level 4, which applies to eCommerce sites processing less than 20,000 transactions annually. The highest and most stringent is PCI level 1, which applies to merchants processing over 6 million transactions a year. Ultimately, the goal is to increase security for all Web sites accepting payment via credit card. 2Checkout completes an annual audit for PCI compliance, which we take pride in maintaining consistently.

Level 4 merchants are typically subject to completing an annual self-assessment questionaire, which contains approximately 220 questions. Furthermore, annual external quarterly scans are a common requirement. The exact requirements are typically set by the merchants’ bank.

Smaller eCommerce sites that have credit cards compromised can be fined between $20 and $30 dollars per each stolen credit card up to $500,000 dollars. Additionally, depending on the size of the breach, the site could be required to hiring an external forensic investigator. The cost of an external audit typically begins around $10,000.

A report published recently by ECommerce-Guide.com identifies increased scrutiny that PCI Level 4 eCommerce sites are being subjected to.

The cost of becoming PCI compliant can be substantial. Especially if your Web site was not initially designed with security being a focus. The requirements cover all aspects of business: technology utilized and how it is implemented as well as business processes and workflow.

Becoming a 2Checkout supplier can quickly enable PCI compliance for your eCommerce site, while keeping the cost of doing business lower in the long term. A 2Checkout supplier will not be required to complete any PCI compliance forms. No changes to your servers or business processes will be required! This is one of the many areas where 2Checkout provides more value to you, our customers and suppliers.

Article was updated on 9/21/2009 clarifying requirements for “PCI Questionnaire A.”

Article was updated on 11/9/2009 to eliminate possible ambiguity in supplier obligations.

2CO meets PCI requirements so you don’t have to!

When considering the best way to sell your products over the internet, one of the most important aspects to look at is the security of customer data. Credit card companies require all merchants to follow extensive security guidelines, called the PCI DSS, which describe every aspect of how the customer’s information is handled. Meeting the requirements set forth in the PCI DSS can be an expensive and time consuming endeavor. 2Checkout takes on the responsibilities of PCI DSS compliance for our suppliers, saving you time and money.

Continue reading…

The ability to include ‘demo=Y’ to return to the vendor defined approved URL without placing a valid order is not a security flaw or error, it is the intended usage of this parameter. It is included in the parameter set in order to allow for vendor testing, from the start of the order process (passing the parameters to 2checkout’s purchase routine), to the end of the order process (returning to the Approved URL defined by the vendor).

It is true that if a vendor defines an approved URL that allows access to the downloadable product/service they are selling, and the vendor takes no further security precautions, someone could download the product/service by including the ‘demo=Y’ parameter.

The ability to control the demo parameter is available from inside the 2Checkout system. You can choose from the following 3 options inside of your 2Checkout account to control the use of the Demo parameter. Those choices are:

• On: Using this setting all sales will be treated as demo, regardless of any parameter value.
• Off: Using this setting all sales will be treated as live, regardless of any parameter value.
• Parameter: Using this setting a demo parameter sent to the purchase routine will control the demo setting.

To access the Demo setting in your account you will need to log in to your account and then click the Account tab. On the Account page click the Site Management sub-tab. After you have selected the Demo setting that best fit’s your current need and then click the blue Save Changes button at the bottom of the page.

It is not recommended to provide a downloadable product/service to a customer immediately after a sale completes by means of a return to the Approved URL. It is recommended to allow the fraud review process to complete before providing your customer with the product/service.

We realize that some vendors may not wish to wait for the fraud review process to complete before providing their customer with a downloadable product/service. For such vendors, the MD5 hash is provided to help verify the authenticity of a sale. We intentionally break the hash code that is passed back if the ‘demo=Y’ parameter is used. You can compare the value of the hash we pass back with the value of what the hash should be (this needs to be calculated on your end). This will allow you to determine whether or not to provide the customer with the downloadable product/service. It should be noted that when using this method to provide a downloadable product/service immediately, you do run the risk of having your product/service stolen by someone placing a fraudulent order with a stolen credit card.

For full details on using the MD5 hash please refer to the article How do I use the MD5 Hash?

If you choose to provide a downloadable product/service immediately after a sale using the Approved URL, and do not check the MD5 key which is passed to the Approved URL to verify the validity of the sale before providing a customer with a product, then you are accepting the risk that your product may be taken without being paid for by someone who includes the ‘demo=Y’ parameter.

The MD5 hash is provided to help you verify the authenticity of a sale. This is especially useful for vendors that sell downloadable products, or e-goods, as it can be used to verify whether sale actually came from 2Checkout and was a legitimate live sale. We intentionally break the hash code for demo orders so that you can compare the hash we provide with what it should be to determine whether or not to provide the customer with your goods.

To calculate the MD5 hash, you need to make a string that contains the information described below and pass it in as the value to your scripting languages MD5 function. Below is an example:

md5 ( secret word + vendor number + order number + total )

The secret word is set by yourself on the Site Managment page. The vendor number is your numerical vendor/seller ID number. The order number is the order number for the sale. The total is the numerical value for the total amount of the sale.

Demonstration:

Secret Word => tango
Vendor Number => 123456
Order Number => 9999999
Total => 5.99

md5hash = md5( tango12345699999995.99 )

It is important to note that the MD5 hash must also be converted to upper case letters for a clean comparison. How this is done depends on the scripting language that you use. Below are some examples of how to compute the MD5 hash using PHP. This should illustrate how this process works.

The following code would be applicable to orders placed using our Plug and Play cart and our proprietary third party set of parameters.

$string_to_hash = “tango123456″ . $_POST["order_number"]
.
$_POST["total"];
$check_key = strtoupper(md5($string_to_hash));

echo (”Returned MD5 Hash : ” . $_POST["key"]
. “<BR>”);
echo (”Should be : ” . $check_key . “<BR>”);

if($check_key == $_POST["key"]){
// At this point the expected key and the returned key match, so the customer should be given access to the download
// This is where you would want to put the code or page for the download
echo (”<center>They match!</center>”); }
else {
// At this point the keys do not match, so either the attempt was fraudulent or a demo order
// This is where you would put the code or page for an unsuccessful attempt
echo (”<center>They do NOT match! Was this a demo order?</center>”);}

The following code would then be applicable to orders placed using the Authorize.net
parameter set.

$string_to_hash = “tango123456″ . $_POST["x_trans_id"]
.
$_POST["x_amount"];
$check_key = strtoupper(md5($string_to_hash));

echo (”Returned MD5 Hash : ” . $_POST["x_MD5_Hash"]
. “<BR>”);
echo (”Should be : ” . $check_key . “<BR>”);

if($check_key == $_POST["x_MD5_Hash"]){
// At this point the expected key and the returned key match, so the customer
should be given access to the download
// This is where you would want to put the code or page for the download
echo (”<center>They match!</center>”); }
else {
// At this point the keys do not match, so either the attempt was fraudulent
or a demo order
// This is where you would put the code or page for an unsuccessful attempt echo (”<center>They do NOT match! Was this a demo order?</center>”);}

The MD5 hash is also provided to help you verify the authenticity of INS posts. The MD5 hash that is sent with INS posts is a hash of sale_id + vendor_id + invoice_id + secret word in the md5_hash parameter.

Demonstration:

sale_id => 9999999999
vendor_id => 123456
invoice_id => 1111111111
Secret Word => tango
md5hash = md5( 99999999991234561111111111tango )

The following code would be applicable to orders placed using our Plug and Play cart and our proprietary third party set of parameters.

$string_to_hash = $_POST[“sale_id”] . “123456” . $_POST[“invoice_id”] . “tango”;
$check_key = strtoupper(md5($string_to_hash));
echo (“Returned MD5 Hash : ” . $_POST[“md5_hash”]
. “
”);
echo (“Should be : ” . $check_key . “
”);
if($check_key == strtoupper($_POST[“md5_hash”])){
// If the expected key and the returned key match the authenticity of the message has been validated.
echo (”They match!”); }
else {
// At this point the keys do not match.
// This is where you would put the code for an unsuccessful attempt.
echo (“They do NOT match!”);}

Please note that help with implementing the MD5 hash into your return script is beyond the realm of 2Checkout.com’s support. This document is provided merely as a reference document to help point you in the right direction. How the MD5 hash is computed is dependent upon the scripting language that you use. Implementation of any MD5 hash checking is solely on your end or your server. 2Checkout.com can not provide you with support in implementing this or troubleshooting your implementation. We provide you with the hashes as a convenience to help you protect your digital goods.

The following links may be of interest to you if you are looking for more information on the MD5 algorithm and its use.

http://userpages.umbc.edu/~mabzug1/cs/md5/md5.html
http://en.wikipedia.org/wiki/MD5
http://msdn.microsoft.com/library/en-us/cpref/html/frlrfSystemSecurityPolicyHashClassMD5Topic.asp

We have also intentionally designed the MD5 hash not to work for demo sales as was explained earlier. If the sale is in demo mode, the order number used to create the hash will be forced to a one, which will cause the hashes to be different when you compare them. If you wish to test the hashes, you’ll have to place a live test order using a real credit card number.