4 ms·
Thank you for the link. That sentence is wrong, I'll fix it to say something along the lines of "your PCI compliance scope is reduced to the things Stripe requi
by zrail 13y ago
Thank you for the link. That sentence is wrong, I'll fix it to say something along the lines of "your PCI compliance scope is reduced to the things Stripe requires you to do on their security guidelines[1]"
(edit: For what it's worth my book does not make the same mistake, and in fact has a whole chapter dedicated to PCI and HTTPS implementation.)
[1]: https://support.stripe.com/questions/do-i-need-to-be-pci-compliant-what-do-i-have-to-do https://support.stripe.com/questions/do-i-need-to-be-pci-com...
- patcheudor 13y agoAwesome!
- pbreit 13y agoSo do Stripe merchants have to fill out and/or file any PCI DSS compliance materials?
- zrail 13y agoAccording to Stripe themselves, no. Honestly most of PCI is common-sense stuff that you should be doing anyway (firewalls, restricting access, etc) but the compliance audits are strictly optional with Stripe as long as you're serving over HTTPS and are using their tokenizing javascript.
- patcheudor 13y agoThen Stripe might want to reconsider their guidance in light of the PCI guidance on tokenization. Reference: "2.4.2 Merchant Responsibilities" https://www.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf https://www.pcisecuritystandards.org/documents/Tokenization_... The only way out of being responsible for PCI compliance would be to offload the entire transaction to the payment provider. This means sending the customer entirely off domain of the merchant (iFrames don't get you there) so that the entire same origin of the transaction is within the complete control of the payment provider. The second the merchant loads an iFrame or any JavaScript within their same origin, they are accountable, period.
- deleted 13y ago[deleted]
- pbreit 13y agoAfter reading the doc and paying close attention to that section, it's not clear to me what the Stripe problem is. I didn't see anywhere that the Stripe approach would not comply.
- patcheudor 13y agoBecause the merchant is still responsible for delivering the payment form within their same origin in a secure manner which means that the merchant must secure their hosts so that the delivery of that payment form cannot be tampered.
- patcheudor 13y agoWow, I just checked their guidance & they absolutely need to reconsider their guidance: "Do I need to be PCI compliant? What do I have to do? Anyone accepting credit card payments must be PCI compliant—but with Stripe, it's easy: Serve your payment page over SSL, i.e., the page's web address should begin with "https", not "http". Use Stripe.js as the only means by which you accept payment information and transmit it directly to Stripe's servers. By taking these steps, you completely avoid handling sensitive card data, and keep your systems out of PCI scope." So use SSL and Stripe.js and I guess you can use all default passwords, not implement anti-virus and allow XSS, SQLi, command injection, and code injection vectors to run wild on your server? After all, none of those could possibly be used to nuke Stripe.js and replace it with code of choice by an attacker? They are providing highly suspect guidance for sure. https://stripe.com/us/help/faq#pci-compliance https://stripe.com/us/help/faq#pci-compliance
- pixl97 13y agoJust over 'SSL' itself isn't enough, even if it was enough. There are so many broken configurations and weak ciphers that just having a lock on your url bar isn't enough. https://www.ssllabs.com/ssltest/index.html https://www.ssllabs.com/ssltest/index.html
- patcheudor 13y agoYup, and that's just the start of the issues when it comes to trying to side-step PCI compliance through claiming tokenization takes care of it all.