Don't Be Insecure. Be Afraid.

One of the most important requirements to e-commerce is security. Unfortunately, there's no magic bullet that will make you secure, nor is there a way to fully outsource your security (though you can radically reduce your burden by using a hosted e-commerce platform like FoxyCart). This chapter exists to inform you about potential threats, common insecure practices, and best-practices.

One of the common complaints we hear from people getting started with e-commerce is:

I couldn't care less about this technical stuff. Security isn't my job! That's what I'm paying you for!

If only it were so easy. The simple fact is that anybody with access or even knowledge of an e-commerce website can potentially put the security of the entire system at risk. For example, many people use the same password for their email, website administration, and on random sites they visit. If any one of those sites is compromised, a malicious user could potentially reroute all your hard earned sales to their own bank account. So even though we at FoxyCart take our security very, very seriously, you could still create problems if you aren't familiar with basic security concerns.

Companies both giant and teensy get attacked every day. If you have a website available to the public, we'd bet dollars to donuts that it's getting attacked by bots on a daily basis. An ounce of prevention is worth a pound of cure, and a security breach averages between $150-$200+ per stolen customer record ^{1) 2)} (though various state and federal fines can easily double or triple that figure, depending on the residencies of the impacted customers and the nexuses of the breached company).

So, yes, we're paranoid. But that doesn't mean they're not out to get us all.

If you've been looking at e-commerce or gateway solutions for more than a few minutes, odds are that you've seen references to PCI DSS. While we can't give you specific advice relating to your own compliance requirements, we can help you understand some of the more important pieces of PCI DSS compliance.

First, it's important to know that the Payment Card Industry Security Standards Council (PCI SSC) is made up of the major card payment brands like Visa, MasterCard, AmericanExpress, and a few others.³⁾ They put together the Data Security Standard (DSS), giving us PCI DSS. There are a few different levels of PCI compliance, and determining your level of compliance can sometimes be tricky. The multiple levels of PCI compliance is further complicated by the considerable amount of FUD and outright misinformation that is used to try to make a sale, sometimes for a product or service that you may not need as a merchant.

The two “deliverable” requirements of PCI DSS are:

1. The Self-Assessment Questionnaire (SAQ), ranging from SAQ A through SAQ D. The SAQ A is very short, while the SAQ D has over 200 questions and requirements.
2. The Security Scan from an Approved Scanning Vendor (ASV).

You may be told by your merchant account provider or gateway that you are required to purchase a security scan through them in order to be PCI compliant, or that paying for a service will make you compliant. That is dangerously misleading information; simply paying for a service will not make you PCI compliant, as compliance can involve things like security training, paper shredding, and business policies and procedures that simply cannot be addressed by paying a 3rd party a monthly fee. So while the SAQ and the scan from an ASV are the pieces that are required to show compliance, they aren't simply things you pay for and magically become compliant.

Though we cannot tell you with certainty what your compliance requirements may be, we can offer a set of guidelines that may help you discern when you do actually need to pay for a service to become compliant (and conversely, when you're being sold misinformation or FUD). This is not an exhaustive list of scenarios, and more information is available at the PCI DSS site if you need clarification.

If you're being told by your merchant account provider or gateway that you need to pay a fee to become compliant, be sure to understand the actual requirements. In many cases you may not need a scan at all, and your SAQ requirements may be quickly and easily completed without paying any additional fees.

Additionally, there are different merchant 'levels' that you should be aware of if you're doing more than 20,000 Visa transactions per year.

If you can limit your exposure to PCI DSS, we recommend it. Because there is no way to get a fully branded checkout experience without at least some level of PCI compliance, we generally recommend not using any virtual terminal functionality and completing the very short SAQ A. If you do need to use a virtual terminal, you'll likely be required to do the SAQ C. The one thing you really (really) don't want to do is store credit cards on your end, as the requirements become very complex and costly. And since FoxyCart handles this storage for you, there's little reason to spend the months or years and many thousands of dollars on becoming compliant at that level.

Your PCI DSS compliance will most likely be addressed when you set up a merchant account, though sometimes it will happen after the initial setup. As mentioned above, some processors have converted PCI DSS compliance into a profit point by tacking more onto the fees.

• Some processors charge $149 annual PCI compliance fee plus another $99 annual fee. (This is generally pure profit for the provider.)
• Others charge up to $19.95 per month on PCI compliance fees.

Again: Simply paying for a service will not make you PCI compliant, as compliance can involve things like security training, paper shredding, and business policies and procedures that simply cannot be addressed by paying a 3rd party a monthly fee. So if your merchant account provider or gateway tries to sell you on any services, make sure you actually need them (per the table above).

It is also important to note that, according to Rey at our friendly preferred merchant account provider (who does not do any of the above fees), “Merchants that haven’t been certified as PCI compliant will have their merchant accounts shut off. Its not a matter of 'if' but 'when'.”

Breach insurance covers the merchant and processor in the event the merchant is PCI compliant but a breach occurs nonetheless. An example is a gas station with pay at the pump. Some people go into the convenience store to buy munchies and then leave the credit card at the counter to fill up the tank. That exposes the merchant to credit card number theft by any employees working behind the counter. This type of CC theft also happens very often in restaurants when waiter/waitresses carry the cards back to the cash register.

If you are concerned about this type of issue, your merchant account provider may be able to provide this for you. One of our recommended merchant account providers, Total-Apps, has options starting at about $20/quarter.

Please read more about how FoxyCart is a PCI compliant service provider. If you yourself need to be PCI compliant at any level, you are required to ensure that your service providers are also PCI compliant.

The most important misconception to address right off the bat is about email privacy and security. Simply put, email is not a secure means of communication unless it is encrypted via S/MIME or PGP (GPG). Even amongst people who know what those abbreviations actually mean they're not commonly used, for all intents and purposes you can assume that emails are fundamentally insecure.

Wikipedia has an in depth discussion of privacy and security relating to email, but here is a short summary of issues ⁴⁾:

• E-mail messages are generally not encrypted.
• E-mail messages have to go through intermediate computers before reaching their destination, meaning it is relatively easy for others to intercept and read messages.
• Many Internet Service Providers (ISP) store copies of e-mail messages on their mail servers before they are delivered. The backups of these can remain for up to several months on their server, despite deletion from the mailbox.
• The “Received:”-fields and other information in the e-mail can often identify the sender, preventing anonymous communication.

To drive that home, let's imagine a single email from Alice to Bob with Alice's credit card number in it. Once the email is sent and received, the credit card is either stored by or has passed through:

1. Alice's computer itself, keeping a local copy in the sent mail folder.
2. Alice's mail server (like Gmail, Hotmail, etc.), which keeps a copy in the sent folder.
3. Likely at least two or more backup servers at the mail service provider.
4. Probably about 6-12 mail servers in between Alice and Bob. (Connections aren't A to B on the internet, but rather hop along multiple servers.)
5. Bob's mail server.
6. Bob's helpdesk or CRM software's database, if applicable.
7. Bob's local computer.
8. Bob's iPhone, perhaps.

It should hopefully be clear that if any one of those points is compromised, Alice may now be dealing with an emptied bank account, overdrafts, considerable time wasted, and etc.

Even if your company manages its own mail servers, you trust your systems administrators with your life, and you maintain strong passwords and anti-virus protection on your computers, pay attention to the second bullet point there. In order to get from the sender to you, the recipient, an email bounces across many, many servers on its way. While it's doing this bouncing it is entirely unencrypted and can be intercepted. If one of those servers has been compromised it could be looking for emails coming through with 9- or 16-digit strings (social security numbers or credit card numbers, respectively).

Have you been emailing credit card numbers and passwords back and forth for years without consequence? Possibly. Should you continue? Not at all, especially not with any data belonging to your customers (as doing so violates agreements you've made with your merchant account provider at very least, and may violate state or federal laws depending on your location and the residency of the customer in question).

It should be noted that mail servers are increasingly supporting a protocol known as TLS (or SSL), which does actually encrypt email in transit, but not “at rest.” So the above example would change a little, and the email would be secure between Bob's mail server and Alice's. Unfortunately, not all mail servers support this, so unless you're sure that both your own mail server and your recipient's mail server support TLS, you should assume that they do not.

While TLS does help in transit, once an email arrives it is still stored in the clear on your mail server and (likely) in your email client (on your phone, desktop, or etc.). In some cases this may not be a big deal, but you still likely do not want sensitive information stored unencrypted.