Documentation You are here: start » primer » security

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.

Security is for EVERYBODY

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.

PCI DSS: What It Is and What It Means To You

What Is the PCI DSS?

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.3) 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.

What Are the Requirements for PCI DSS?

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.

What Are Your Compliance Requirements?

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.

SAQ Required Scan Required How you collect payments
None No
  • Payments are only handled on a 3rd party system such as through PayPal Express Checkout through FoxyCart or Google Checkout. (These types of payment methods are fundamentally different than a “real” gateway in that the funds are transferred first to the 3rd party (ie. PayPal), then transferred to you. PCI DSS generally only applies to merchants with a Merchant ID, receiving payments directly.)
SAQ A No
  • Payments are handled through your store's FoxyCart checkout using a “real” gateway (ie. a gateway that doesn't redirect the customer to their own hosted payment page).
  • Payment card details are never handled on the phone or using FoxyCart's Unified Order Entry or with any other virtual terminal.
  • No cardholder data storage, ever. (ie. You never store card numbers, anywhere, ever, at all.)
  • No fees should be charged by your merchant account provider if you fall under PCI SAQ A (unless breach insurance is required, which is discussed below).
SAQ B No
  • Payments are handled through standalone terminals or are swiped using a machine.
  • No cardholder data storage, ever. (ie. You never store card numbers, anywhere, ever, at all.)
  • No fees should be charged by your merchant account provider if you fall under PCI SAQ B (unless breach insurance is required, which is discussed below).
SAQ C Yes…
  • The SAQ C isn't really intended to be used for e-commerce, but rather for individual retail stores.
  • Payments are entered with a payment system connected to the internet. Systems used to access the virtual terminal may need to be scanned by an ASV.
  • No cardholder data storage, ever. (ie. You never store card numbers, anywhere, ever, at all.)
SAQ C-VT No…
  • This is new as of PCI DSS 2.0, but it explicitly states “e-commerce merchants will never qualify for this version of the SAQ”, so we won't cover it here. If you're interested though…
  • Payments are entered into a web browser-based virtual terminal, “via a computer that is isolated in a single location, and is not connected to other locations or systems within your environment (this can be achieved via a firewall or network segmentation to isolate the computer from other systems)”.
SAQ D Yes, on applicable systems
  • If you don't fit under the above SAQs, SAQ D is what you fall under.
  • Cardholder data is transmitted or stored on systems you control, regardless of the payment methods. Systems that transmit or store cardholder data will need to be fully PCI compliant and scanned by an ASV.
  • If you have servers or hosting that touches credit cards at all (even if it's just a POST to your website that then sends it to the gateway), you fall under the SAQ D.
  • This is full PCI DSS compliance, 200+ requirements, though some of them may not apply. If you can avoid this, you should. There are many solutions (including FoxyCart) that give flexibility without exposing your systems to cardholder data.

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.

Becoming PCI Compliant

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).

Breach Insurance

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. Our recommended gateway partner provides breach insurance included at no extra cost (so long as you keep your SAQ up to date, which they provide a tool to assist with as well).

So What About FoxyCart's Compliance?

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.

Bad Ideas: Email and Sensitive Information

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 4):

  • 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).

The Takeaway: Email Never, ever send sensitive information over email. This includes credit card numbers, passwords, social security numbers, or anything else you'd be embarrassed or liable for should it fall into malicious hands.

TLS / SSL Encryption and Email Security

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.

1) “Data breach costs top $200 per customer record”, NetworkWorld.com
2) Data Loss Calculator by Tech-404.com
4) Copied from Wikipedia's email entry

Site Tools