Hacker News Reader

Comment by cperciva | Hacker News Reader

The PCI rules only apply to systems which touch credit card data -- not to a system which serves up a credit card form.

That's not universally true. Unfortunately, the PCI DSS is somewhat subjective and enforced inconsistently, so it's difficult to definitively answer what's required for PCI compliance for a certain type of payments integration.

Even for merchants that use third-party hosted payment forms, it's still common to need to complete SAQ A (a short self-assessment questionnaire) and have quarterly network scans. For example, with PayPal[1]: "Our hosted solution takes a lot of the work out of meeting these standards. The only remaining requirements are a Security Self-Assessment Questionnaire (SAQ) and Quarterly Security Scans."

According to MasterCard[2]: "All merchants that store, process, or transmit cardholder data must be PCI compliant." It's subjective whether using Stripe.js could be considered transmitting cardholder data.

Visa[3] holds Acquirers responsible for ensuring their merchants are PCI compliant. Requirements vary depending on processing volume: "In addition to adhering to the PCI DSS, compliance validation is required for Level 1, Level 2, and Level 3 merchants, and may be required for Level 4 merchants." Notice that for Level 4 merchants, validation only may be required, although those merchants should still be adhering to the PCI DSS.

Stripe has several PCI requirements in their terms of service[4], and their FAQ does seem to indicate[5] that merchants have some responsibility for PCI compliance. According to the TOS "It is your responsibility to comply with these standards." and according to the FAQ: "Most Qualified Security Assesors (QSAs) will want to talk through many of the implementation details before giving an opinion"

Disclosure: I work for Braintree.

Disclaimer: This response is my opinion; I'm not speaking for Braintree.

[1] https://merchant.paypal.com/us/cgi-bin/?cmd=_render-content&...

[2] http://www.mastercard.com/us/company/en/whatwedo/determine_m...

[3] http://usa.visa.com/merchants/risk_management/cisp_merchants...

[4] https://stripe.com/terms/US

[5] https://answers.stripe.com/questions/what-exactly-do-i-need-...

Sorry if I misunderstand. Aren't you(paymentiframe) processing the form which is touching the data and then passing the data onto Stripe via their API?

The iframe uses Stripe's javascript to send the card details directly to Stripe's servers -- the only thing which hits the tarsnap server is a token which Stripe returns (and nothing at all goes back to the server hosting the iframe).

This approach of Stripe's has always seemed like a bit of a shell game to me, but I can only assume it's been deemed PCI compliant.

As I point out in my blog post, what the networks care the most about is ensuring that there aren't months or years worth of cards stored anywhere which might leak out. Having a site get compromised and a few days of cards stolen is orders of magnitude less important.

I think the point was frustration over the disconnect between PCI rules and reality, that there's no difference in security between self-hosting the form action (over ssl, sending the cc info to the payment processor, and getting a confirm that way), compared to hosting an iframe and "not touching" credit card data. A compromised webserver means the iframe can be compromised so that the card details do hit your server.

There is a difference: If the data never touches your server at all, it is impossible for you to inadvertently record it.

If the iframe that you host is compromised, you have no idea where that info is being recorded. The fact that it doesn't touch your server doesn't ensure that your site isn't leaking numbers.

Certainly. But it does ensure that access to your server does not entail access to historical numbers.

Unless the compromise is a long-term one.

Part of what PCI attempts to address is limiting legitimate access to servers, as well as preventative measures against compromise.

I personally think that Stripe may be within the letter of the law, but not necessarily the spirit.

I loved how you wrote that! Whenever people talked about stripe I always thought: Stop, wait! What if your server is compromised? You can do any change to stripe.js you like using malicious injected code. Many people would just handwave that away, but you write it perfectly clear and give the reason why what stripe does still helps: It basically just avoids the PCI checks without being secure ;-) No, you wrote that it avoids having you inadvertently store the data.

More people should write about obvious security holes so clearly and logically correct like you do

Reply on news.ycombinator.com