Adventures in PCI compliance

Garrett Albright's picture

Inspired by the "Storing credit card numbers" thread, let's talk about what it takes for a site, particularly a Drupal-powered shopping site, to become and to stay PCI compliant, and for keeping our sites secure in general.

A side effect of FOSS shopping cart systems like osCommerce, Magento, and of course Ubercart and Drupal e-Commerce is that they're commonly used by smaller stores or one-man shops who may not be aware of the standards in this regard, or have enough knowledge to comply with them - or maybe even they just don't care. It doesn't help that a lot of info out there about security can alternate between being utterly boring and utterly confusing.

Fortunately, Wikipedia's article on the Payment Card Industry Data Security Standard is blissfully short and easy to read, though it does only list the basics. Some of the elements which stand out to me are:

1. Install and maintain a firewall configuration to protect cardholder data. Probably impossible if you're using a shared hosting service to host the site due to lack of budget and/or tech savviness. I've been looking in to getting PF up and running on our company's spiffy new FreeBSD server, but it's a bit complicated and I'm afraid I'm gonna end up locking myself out…

2. Do not use vendor-supplied defaults for system passwords and other security parameters. The biggest weakness I can think of here with regards to Drupal is that its most common database back-end, MySQL, by default allows remote connections, and has a blank password for the root user. If you correctly followed installation instructions, you should have at some point changed the root password; as for the former issue, you should add the line skip-networking under the [mysqld] section of your my.cnf file - again, this might not be easy if you're on shared hosting. Restart the daemon, then telnet <hostname/IP address> 3306. You should be told to get lost. Even if you're not using Ubercart, this is a pretty smart practice to follow - the fewer open ports on your machine, the better.

4. Encrypt transmission of cardholder data across open, public networks. In other words, use SSL/HTTPS. Duh.

5. Use and regularly update anti-virus software on all systems commonly affected by malware. In other words, be vigilant about malware if you're hosting on Windows - or be really vigilant and don't host on Windows in the first case.

10. Track and monitor all access to network resources and cardholder data. Another requirement which may be difficult to fulfill on shared hosting.

It's not on this list, but obviously you also want to select strong passwords for everything - for your user account on the web server, for all MySQL accounts, and for all administrator Drupal accounts. For passwords that I don't have to type often, such as MySQL user passwords which I rarely use after putting them in settings.php, I like to use the Strong Password Generator site to generate a fourteen-character password full of nonsense. They're not easy to remember for passwords you have to type often, though. For those, remember - at least seven characters, using capital letters, lowercase letters, numbers, and at least one symbol. For just a little more security, don't use a common name like "bob" for the user account username, since brute force attacks typically work by trying common usernames together with common passwords. If you're in a position where you can choose someone's username but they will be able to change their own password (to something like "password," for example), giving them a username like "su5Anj0nEs6" might be your only salvation… (And for Pete's sake, never use a username like "admin" or "root" if you can help it…)

Also, when installing third-party modules, be careful to only use ones you've downloaded from Here's a possible attack vector; I hack Views or some other common module to include a hook_form_alter() hook which takes note when a user is submitting a payment form and emails me the credit card details. I then advertise it on an IRC channel or forum or such as my own improved version of Views which works 200% faster than the original, knowing full well that most of the people who try it won't bother to see if that's really true - or what else the module may be doing. You download and install the module, and now I have your customers' credit card data. Sticking only to modules on doesn't totally insulate you from this kind of attack, but at least you'll get some assurance that thousands of other developers can easily take a look at that code at various points in time and make sure it's not and has not ever done anything like that. And just in general, both for speed and for security reasons, you really do want to use as few modules as necessary on any given site…

I think Ubercart itself is helpful with regards to maintaining customer safety, such as with its ability to delete credit card numbers from permanent storage after a payment is completed. It would be really awesome if that data could be "whited out" with zeros or random data on the physical hard drive somehow, but that's at a far lower level than Ubercart operates, obviously.

Enough blathering from me. Your thoughts?


This is very helpful. I am

burtsbees's picture

This is very helpful. I am trying to become PCI compliant in order to run Paypals website pro gateway on my site. For someone with limited knowledge, it has been pretty confusing. For now, I am working on getting on a virtual private server (I don't know if this is equivalent a dedicated server security wise, but it is all my hosting company offers), a dedicated IP address, and an SSL certificate. I am going to see where that takes me. Last time I had my site scanned for PCI compliance by McAfee, they found these problems:

1.Darwin Streaming Server < 5.5.5 Multiple Remote Overflow Vulnerabilities

2.PHP version check

3.Web Application Cross Site Scripting

4.Unencrypted Login Information Disclosure (

5.Potential Sensitive Persistent Cookie Sent Over a Non-Encrypted (SSL) Channel

Hoping that some of them will be fixed.

PCI Compliance and Persistent Cookie

aasarava's picture

Burtsbees, were you able to resolve issue #5, regarding the "Potential Sensitive Persistent Cookie Sent Over a Non-Encrypted (SSL) Channel". Would be very interested to hear what you ended up having to do.

I have a client using the MerchantPlus gateway and is being required to be PCI certified. A McAfee scan turned up the same persistent cookie issue that you noted (among other minor issues.) Curious if there's a solution, or info on why it's not an issue for Drupal.


Network Security is Scrutinized Under New Standards

ahimsauzi's picture

I am dealing with a failing scans on one of our clients and most of the failing issues has to do with network security, TCP version, Apache version below 2.2.16 as well as any SSL 2.0.

After a few hours of research I found out that the current trend if to target level 4 sites due to their lack of secured infrastructure and IT support. This particular site is hosted at Media Temple who flat out report that their servers are not PCI Compliant (although their DV can be made compliant with additional configuration not offered by MT).

Does anyone have any recommendation for a hosting provider that is PCI Compliant or better yet guarantee compliance?

I am not a server admin by any means but this current requirement by credit card industry does open a new niche for those who can provide on going network security.

Why Retain Credit Card Data and Satisfy PCI Compliance?

jmahan's picture

I understand the argument that many Drupal Commerce sites are run my small, non-technical owners who are not equipped to support or fund PCI Compliance. I also understand that even Magento Commerce offers a limited solution in the Community Edition that requires going to the Enterprise Edition to achieve higher levels of PCI Compliance and Credit Card Data Control.

My recent brainstorming as JohnM in the DrupalCommerce Forum seems to indicate that for now "Core Drupal/DrupalCommerce" is not taking on this challenge but relies on the Merchant Gateways to manage data and comply. So we spend our time on catalogs, etc.. at the risk of having core solutions that are not capable of serving the needs of BIG Stores. If this is true we may be missing the chance to architect a PCI-compliant, Retain Credit Card Data-friendly solution in DrupalCommerce that at least could be available as an option?

IMHO the most difficult challenge, data encryption can be solved at minimal cost ($40/month) seamlessly to the solution... and the encryption engine can make all other sensitive data stronger... a win/win.

I believe it is good for a Store to focus on the Customer and make it easy to switch to any payment source, on demand, while retaining control of the Customer Data. Maybe it would be good to be more aggressive on this issue in core D7 and D7DC to set the bar higher and be able to support the small stores that become big and save money for the small stores until they become big?

I took a look at the

threading_signals's picture

I took a look at the wikipedia page that Garrett mentioned, and here's what I know/want to know:

Build and Maintain a Secure Network

1) Install and maintain a firewall configuration to protect cardholder data
Using iptables or PF as the first line of defense. Stuff like fail2ban, builds on them.

2) Do not use vendor-supplied defaults for system passwords and other security parameters
See op. SQlite3 doesn't come w/ any passwords, but there's a terminal available. Postgresql comes with ident based checking as a default.

Protect Cardholder Data

3) Protect stored cardholder data
Is database protection enough or salted table?

4) Encrypt transmission of cardholder data across open, public networks
See op.

Maintain a Vulnerability Management Program

5) Use and regularly update anti-virus software on all systems commonly affected by malware
Clamav uses less resources, but use more than one if you want more definitions/detection engines.

6) Develop and maintain secure systems and applications
Drupal is more secure than Joomla according to Secunia:
This is a reflection on Drupal policies/culture and the Security Team.

Implement Strong Access Control Measures

7) Restrict access to cardholder data by business need-to-know
Sys admin command line knowledge on the technical side.

8) Assign a unique ID to each person with computer access
Useful for auditing, but this info also needs protection.

9) Restrict physical access to cardholder data
How does colo workers figure into this?

Regularly Monitor and Test Networks

10) Track and monitor all access to network resources and cardholder data
Snort and other solutions give you a checkmark here:
The requirement is vague though to me though, and there's a U.S. law against unauthorized tracking and monitoring.

11) Regularly test security systems and processes
The page is for 1.2 compliance. #1-12 of this discussion notes some of the differences. There are 2.0 free checking solutions after signing up.

Maintain an Information Security Policy

12) Maintain a policy that addresses information security
2.0 free compliance checkers should help out on this one.

FYI - edited, drupal automatically marks up the #ing, based on carriage returns.

Still an Issue, But New Outsourcing Options Exist

rickmanelius's picture

This thread is over 2 years old, but it's still relevant. In fact, it's probably MORE important because the number of active Ubercart and Drupal Commerce installations continues to grow while the requirements (PCI SAQ 2.0 went into effect January 1st, 2012). But what this thread does not cover is how to offload a significant portion of their responsibilities by either re-directing to a 3rd party site OR use some of the new solutions that exist, such as tokenized and iframe methods that allow users to stay on the site and yet post the payment directly to the servers of the payment processor.

I wrote an article on this a few days ago that has received a lot of positive feedback. It's not 100% comprehensive, but within it I do propose using this as a launch point to create a full fledge whitepaper.

Very important information

MarketStone's picture

Very important information, thanks for the post. Just how little people know about security., godaddy and facebook all have there ssl wrong, twitter finally has it right. A hand shake has to be made between Your computer and the server if You are using a JavaScript widget or entering Your password on a http page that redirects to a https page it was sent before the handshake was done and was sent unencrypted. It is like someone has asked them to do this on purpose. On all site logins if You do not see https add it in, hit return then add Your password.

Never Never Never keep credit card info. Paypal has spent billions of dollars, they watch all traffic in and out and they are still not 100% secure. Your database is You weakest link, why do You thing the password can only be 14 digits long and can only have letters and numbers? This is Your gov back door.

and i have always said the best thing about drupal is there security team.

Druapl PCI Compliance White Paper

rickmanelius's picture

Just posting this link here in case someone gets to this thread and is looking for additional information.

Drupal Commerce

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week