PCI commerce Security with Craft: a CraftCMS Slack thread on avoiding private customer information ever hitting your server. The discussion includes Stripe, Joel Bradbury's Charge plugin for Stripe, and Authorize.net. The idea is to avoid the large challenge of gaining actual PCI certification for your server, which would be a bank-level task.

gistfile1.txt

12:06]  
mcclaskiem Anyone have experience with PCI Compliance + Craft

[12:07]  
narration_sd @mcclaskiem:  do you really want to do anything involving PCI on your  own server, or wouldn't off-loading on for example Stripe be a much less agonizing path??

[12:08]  
mcclaskiem I am using Commerce to handle the e-commerce aspect of the website

[12:08]  
and Authorize.net as the payment Gateway

[12:08]  
narration_sd ah, ok -- and that's out of my league, Commerce.

[12:09]  
mcclaskiem Is it more server config or actual code

[12:11]  
matt @mcclaskiem What aspect of PCI Compliance are you concerned with?

[12:11]  
khalwat @mcclaskiem: Typically they have external tests that probe your site, and give you a list of things to fix, or a pass

[12:12]  
mcclaskiem This is my first e-commerce build, and Ive read thats its more server config, like ssh prevention etc

[12:12]  
matt I know it gets hairy and complicated, I’ve worked on a small site with Snipcart + Craft, though we basically use Security Metrics to scan and complain about stuff that needs attention.

[12:12]  
mcclaskiem but wondering if the server code can cause issues as well

[12:12]  
like Craft + Commerce

[12:12]  
narration_sd @mcclaskiem:  Well, the issue is whether PCI-interested customer data (like credit card numbers) ever touches  your  server. And I just looked and found Authorize.net looks to have a Javascript api that avoids this, as Stripe's does. You can read and see whether it looks adequate to you:  https://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/Introducing-Authorize-Net-Accept-js/ba-p/54980
community.developer.authorize.net
Introducing Authorize.Net Accept.js
Today we’re announcing the second module for the Authorize.Net Accept suite of tools: Authorize.Net Accept.js.   This new module makes it easier to integrate payments into applications while helping to reduce PCI DSS scope. With Accept.js, developers have control over the user experience without sen... 
June 29th at 05:56

[12:12]  
matt @khalwat’s right again, and even while on a live public Hangout. The probes will make your life easier, even though it’s a reactionary approach. (edited)

[12:13]  
khalwat @mcclaskiem: I have a client that uses authorize.net — it’s not them, but rather his payment gateway that has tests that run to check the site for compliance

[12:13]  
Funny thing is they still allow you to use the service even if you fail, they just charge you more monthly

[12:13]  
mcclaskiem @narration_sd: I am processing payments through commerce so it will touch server

[12:13]  
narration_sd yes, those probes sound a great thing - glad to hear about them. Though I would stay on the non-PCI side of  the wire...

[12:14]  
mcclaskiem Ya my client said they were charged $20 for non-PCI compliance

[12:14]  
on the first order they got

[12:14]  
so I wanna fix it before they start really marketing the website

[12:14]  
khalwat Usually they suggest a free probe service

[12:14]  
narration_sd well, but that's the point. The isolating apis have you ​_not_​ taking t he credit card info, etc.. It magicallly is taken by the provider's PCI-compiiant back end  only -- you end up dealing with a safe token only.

[12:15]  
matt I generally avoid handling+storing sensitive details for that reason, @narration_sd.

[12:15]  
mcclaskiem Ya we arent storing just processing

[12:15]  
narration_sd well, processing counts. And I think you can be getting into more than a 20-dollar one-time fine

[12:15]  
mcclaskiem Does anyone have a link for one of the probes?

[12:16]  
matt This is the service I’ve worked with: https://www.securitymetrics.com/
 securitymetrics.com
PCI Compliance | HIPAA Security Assessment | SecurityMetrics
Protect your network and your customers with PCI and HIPAA compliance assessments from SecurityMetrics. We offer a full line of data security solutions. 

[12:17]  
narration_sd again, what the apis do is  provide their own form blanks which appear to be a part of your own form, but go only from the web browser to their  compliant server -- returning to you that token. You never 'see' the information in question at  all, just  the token to process. The token in another call to  their back end does the actual charging..this is how you use it to get the transaction done, including error handling etc... (edited)

[12:18]  
Not 'seeing' the dangerous data is what you're after, would think...

[12:21]  
See that link to the api from authorize.net, posted above if it scrolled off screen...

[12:22]  
I've used Stripe's, and it's great, simple (as can be with payments) and also comprehensive. Imagine the one from authorize.net is also.

[12:24]  
mcclaskiem Ya that works

[12:24]  
I am gonna try and make the current set up work

[12:24]  
narration_sd If  you get interested in Stripe, there's also @joelbradbury 's Charge plugin to look over, also great and adding features rapidly (edited)

[12:24]  
http://squarebit.co.uk/software/craft/charge

[12:24]  
mcclaskiem and if its a hastle switch to JS solution (edited)

[12:25]  
narration_sd well, ok -- I judged the hassle of PCI compliance to be orders of magnitude greater -  hope you are clear about that

[12:25]  
don't like legal risk, or providing proofs to agencies, etc....

[12:26]  
you really have to be something of a bank in your approach, from hosting outwards  -- it's a real legal compliance, and tracked ongoing

[12:27]  
https://www.pcisecuritystandards.org/pci_security/
 pcisecuritystandards.org
Official PCI Security Standards Council Site - Verify PCI Compliance, Download Data Security and Credit Card Security Standards
If you are a merchant of any size accepting credit cards, you must be in compliance with PCI Security Council standards. This site provides: credit card data security standards documents, PCIcompliant software and hardware, qualified security assessors, technical support, merchant guides and more. 

[12:29]  
So  you can see who's behind this (Visa,  etc.), and know that they have very heavy hands....

[13:10]  
joelbradbury Just to pitch in here since @narration_sd pulled me in - I've found this a useful a guide when it comes to PCI compliance costs - https://www.braintreepayments.com/blog/what-does-it-cost-to-become-pci-compliant/
 Strongly Typed
What does it cost to become PCI Compliant?
See the average cost of becoming PCI compliant based on your business profile, as well as associated hardware and software cost to maintain compliance. 
June 24th, 2008 at 16:00

[13:12]  
With that in mind - proper stripe (and braintree) setups remove the burden of compliance from the vendor down to the processor (stripe/braintree).

[13:12]  
I would ​*always*​ recommend avoiding PCI compliance requirements wherever possible

[13:13]  
On the note of actually getting level 3 or 4 compliance it can be greatly affected by the server and back office setups you're using

[13:14]  
It can quickly be a time sink, especially when you end up in continuing non compliance

[13:15]  
On the actual time needed to setup things like the stripe js - it can take just minutes. (edited)

[13:15]  
Charge will do ​_everything_​ needed out the box and be fully compliant with setup taking about 2 minutes.

[13:41]  
mcclaskiem @joelbradbury:  Isn’t charge a server side solution as well though?

[13:41]  
joelbradbury Yes

[13:42]  
All the protected values never reach any servers you control.

[13:43]  
It's all tokenised directly via stripe and you only ever see those tokens. The same is true of braintree js setups

[13:45]  
matt It doesn’t matter whether the thing passing data on your end is PHP, JavaScript, or Pascal—it’s whether the stuff touched is sensitive information. PCI compliance wants to make sure you never touch the hot potato (sensitive information), or that you’re wearing a hazmat suit in a bunker if you ​_do_​. Working exclusively with tokens (Stripe, Authorize.net’s JS service, etc.) lets you keep your (site+server) hands clean while still completing transactions. (edited)

[13:47]  
^ Or at least that’s my understanding. Somebody should correct me if I’m wrong.

[13:53]  
narration_sd @mcclaskiem: just to clarify -- if I understand your question to Joel, the answer (as he explained) is No: Charge isn't server-side how you mean. The Charge plugin goes in your Craft install on server, but it implements the Stripe JavaScript api for you, taking care of all the needs and cases. That Stripe api is what keeps the PCI data only on the browser and on ​_their_​ server, so yours safely never sees it. Charge uses the Stripe token to do your transaction, and that token is unidentifiable, safe.

[13:55]  
mcclaskiem Ahh gotcha

[13:56]  
joelbradbury @matt: broadly correct. If your back end never sees any protected values you can be PCI compliant very simply by completing the SAQ-A questionairre which stripe will require you to complete on their site before it'll allow any live transactions.

[13:57]  
There were some changes when PCI DSS 3.1 was introduced, but stripe handle all the extra requirements as long as you're using stripe.js or stripe checkout

[13:57]  
https://support.stripe.com/questions/what-about-pci-dss-3-1

[13:58]  
matt Thanks @joelbradbury. ​_Broadly_​ is as close as I can get, unfortunately :slightly_smiling_face:

[13:58]  
joelbradbury Charge specifically also has some internal safety checks which will disallow any requests that don't meet the requirements.

[14:00]  
Those edge cases will only ever occur if you've misconfigured your payment forms and its more of a forceful kick for the dev to get it sorted than anything else.

[14:01]  
(Itll throw a 403 exception with a notice in that case - http://squarebit.co.uk/software/craft/charge/faq/what-does-the-charge-403-pci-keys-error-mean)

[14:02]  
Happy to talk more or demo anything if there's any questions on the actual devops side (edited)

[14:03]  
matt This smells like it could be a good Stack Exchange question regarding PCI compliance and Craft. Do you (@joelbradbury, @narration_sd) recall any introductions on the subject for a designer/developer type trying to make legally responsible, technically sustainable decisions about a cart system? (edited)

[14:04]  
joelbradbury The big advice id give is to do as little as possible and never roll your own.

[14:05]  
narration_sd @joelbradbury: re correction: yes I couldn't tell if that was an iPadism or relating to the Welsh ;)

[14:06]  
And think Joel's advice is grand, just so

[14:07]  
@matt I confess to thinking it should go somewhere, including link into the Craft commerce section also (edited)

[14:09]  
matt That’s been my general approach (luckily/thankfully), I’ve just been slowly appreciating it more as I’ve gone along. (edited)

[14:16]  
narration_sd Did do a link for the Commerce Slack participants...

[15:19]  
bgarrant joined #devops

[17:54]  
jeremydaalder Hey folks - good chat re: PCI.  Just to give another practical example, to avoid PCI compliance burdens with eWay (who are quite big here in Aus. as credit card processors) - we use their Client Side Encryption (CSE) js library to encrypt cc details with a unique key they give us -> these encrypted details are sent via Commerce/omnipay to eWay and their (obviously PCI compliant) server.  And that's it really, that's all we have to do.  Took about 15 mins of JS work to set up.  Someone good at js would have done it in < 5 I suspect. :slightly_smiling_face:  

I think most payment providers will have some sort of similar option these days - completely agree with @joelbradbury that the key is to do as little as you can and shift this burden elsewhere.