11–20 of 125 posts
Good. There's no love lost between me and companies that make significant money doing PCI assessments (they tend to be the bottom-feeding remora of the infosec economy), but the one criticism you could not level against the PCI certification program over the last 10 years is that it was too hard to get certified . Use Stripe. Move on.
I always recommend people build their payments on Spreedly ( https://spreedly.com/ ). It checks off the boxes for minimizing PCI scope; you store no payment information, and collect none on your website either. You can either do a transparent redirect (your payment form points to a URL on their domain, which redirects back to your site with a token) or an iframe. Once you collect payment information, which they token…
Does anyone know if using transparent redirects actually waives your responsibilities for PCI compliance? Even though the credit card details aren't sent to your backend, they are still collected on a form hosted on your infrastructure. If your servers are compromised and malicious JS is added to your payment form, couldn't an attacker siphon credit card details via AJAX? It seems like the PCI documentation always us…
If your responsibilities weren't waived or significantly lessened, I'd imagine companies like Stripe would be significantly less successful.
Earlier quoted context omitted.
Does anyone know if using transparent redirects actually waives your responsibilities for PCI compliance? Even though the credit card details aren't sent to your backend, they are still collected on a form hosted on your infrastructure. If your servers are compromised and malicious JS is added to your payment form, couldn't an attacker siphon credit card details via AJAX? It seems like the PCI documentation always us…
It's generally transparent redirects in the other direction. You load JS from their servers, the form posts to their servers, redirects back to yours. Often even the form isn't hosted on your infrastructure, but instead embedded into your page through some JS that is hosted elsewhere. If your responsibilities weren't waived or significantly lessened, I'd imagine companies like Stripe would be significantly less succe…
Using an embedded payment form also shouldn't require any JS, as it is usually done using an iframe. This method should be safe, as the same-origin policy in the iframe would prevent JS on your domain from interacting with form elements in the iframe. But this is not typically what people are talking about when they talk about a transparent redirect.
> The new version of Stripe.js meets these criteria by performing all transmission of sensitive cardholder data within an iframe served off of a stripe.com domain controlled by Stripe.
Can someone help me understand how this is practically any more secure than the way Stripe.js currently works? It sounds like the intention of the iFrame exception[2] is to allow a payment form to be loaded, completed, and submitted to a compliant server all within a visible iFrame. From what I can tell, the "compliant" version of Stripe.js just submits the data (similar to the traditional way) via an invisible iFrame - the form is still hosted and completed on the (likely) non-compliant server.
If that's the case, then I'd expect the "loophole" to go away soon and current Stripe.js users will have to adopt a payment flow similar to Stripe Checkout; in other words, it will be obvious that Stripe (a third party) is being used because the end user will be interacting with a form (or part of a form) completely hosted on Stripe's servers.
For companies using Stripe to avoid PCI compliance with self-hosted payment forms, this essentially transforms Stripe into another PayPal checkout-style service.
[1] https://support.stripe.com/questions/what-about-pci-dss-3-0
[2] https://www.pcisecuritystandards.org/documents/Understanding...
Good. There's no love lost between me and companies that make significant money doing PCI assessments (they tend to be the bottom-feeding remora of the infosec economy), but the one criticism you could not level against the PCI certification program over the last 10 years is that it was too hard to get certified . Use Stripe. Move on.
Accepting payments is getting easier, because companies like Stripe will handle the burden of security and compliance.
Stripe is in Visa's doghouse right now.[1] Their entry on the Visa Global Registry of Service Providers has turned yellow, with an expiration date of Mar 31, 2015. This means they're having some PCI compliance problem.[2] Visa gradually cranks up penalties until the problem is fixed, or, after about 9 months, just pulls the plug. Visa says Square and PayPal are OK right now. Yahoo is also in the yellow doghouse. (If you're a Stripe or a Yahoo Store merchant, they were supposed to inform you that Visa put them in the doghouse, so you can change vendors. Did they?)
[1] http://www.visa.com/splisting/searchGrsp.do [2] http://usa.visa.com/download/merchants/Bulletin-PCIENFORCE-1...
This is good. People are getting fed up with replacing their credit card every six months because some online retailer had a breach. You can outsource payment processing to Stripe, Paypal, Square, Yahoo Store, etc. There's no reason every web merchant should see credit card numbers. Stripe is in Visa's doghouse right now.[1] Their entry on the Visa Global Registry of Service Providers has turned yellow, with an expir…
The heightened requirements are actually for when you are using services that _don't_ let the merchant see the CC number. Like the "old" Stripe.js.
Good. There's no love lost between me and companies that make significant money doing PCI assessments (they tend to be the bottom-feeding remora of the infosec economy), but the one criticism you could not level against the PCI certification program over the last 10 years is that it was too hard to get certified . Use Stripe. Move on.
What happens when the iframe allowance is removed, and not even using Stripe can save you from the credit card companies? This seems like a transparent plan to make PCI assessors more money.