Comment by dangrossman | Hacker News Reader

Comment by dangrossman | Hacker News Reader

Parent Full thread

Everything except the parts about storing payment data. In a nutshell:

- Install and maintain a firewall

- Lock down system users, groups, passwords and default settings of your services

- Use encryption

- Use and update anti-virus software

- Restrict access to your systems and have auditable logs of all access to your systems, physical and digital

- Have unique identifiers for all people with access to your systems, so that those audits are meaningful

- Log and monitor all network access to your systems

- Have, distribute, and regularly test your physical, network and information security policies

- Fill out a self-assessment questionnaire attesting you meet all these requirements

- Have your server scanned by a 3rd party compliance company every 3 months

To pass the compliance scans, you will have to maintain all services on your servers at the latest versions or provide evidence that you have applied patches covering all known security flaws, among other things. The scans are not cheap and have to be made by a provider approved by PCI. SecurityMetrics charges $699 per year to do them quarterly.

By signing up with Stripe you are agreeing that you're taking care of this already.

> You agree that at all times you shall be compliant with the Payment Card Industry Data Security Standards (PCI-DSS) and the Payment Application Data Security Standards (PA-DSS), as applicable. You agree to promptly provide us with documentation evidencing your compliance with PCI DSS and/or PA DSS if requested by us. You also agree that you will use only PCI compliant service providers in connection with the storage, or transmission of Card Data defined as a cardholder’s account number, expiration date, and CVV2. You must not store CVV2 data at any time. Information on the PCI DSS can be found on the PCI Council’s website. It is your responsibility to comply with these standards.

https://stripe.com/terms

It's also important to realize that you can't meet all the requirements on shared or cloud hosting -- except Amazon EC2, which is AFAIK the only PCIDSS approved cloud. You really need your own server to be in compliance.

Correct me if I'm wrong, but I thought the whole point of Stripe's JS setup, Braintree's transparent redirect, etc. was that it takes your server out of scope of PCI compliance. Basically my server doesn't "store, transmit, or process" any credit card information (the customer's browser sends it straight to the processor), so it's not within the scope of PCI compliance. The author even hinted towards this in their post.

What Stripe does is a gray area, but something you can be pretty sure the PCI Council will eventually clarify so that these things are clearly covered. They may or may not be now.

Why will it be? Because whether the form submits to your server or to someone else's server is irrelevant. If you have not secured your own server, then someone can redirect the target of that form, or inject their own Stripe-style code to silently send the form contents offsite the same way Stripe does it. And nobody will be able to track down the source of that breach because the site owner is probably not complying with the access control and logging requirements either.

Do you really want people that can barely configure WordPress responsible for the security of your credit card number online? That's the effect of not putting this practice under the scope of PCIDSS. That's probably why the banks underwriting Stripe told them to put the requirement that all their users comply with PCIDSS into their terms of service.

If you want to be outside the scope of PCIDSS, then don't host payment forms. Either redirect to a hosted page, or embed an iframe. Either way, being on a different domain means your own security practices can't compromise the payment data.

I asked stripe about all this in their campfire chatroom last night, and I was hoping they would chime in on this thread, but let me pass along some of what they said.

Their response was similar to what the grandparent articulated: that by using Stripe.js, you're avoiding the storage requirements and thus don't have to do anything extra for PCI. However, you can also interact with their API without stripe.js, which is where you would need PCIDSS and thus the language in the terms.

Now, all that aside, I think you bring up a great point about the gray area and the risk that a security breach would cause. One major difference is that with Stripe.js, a security breach would not put at risk all cards used in the PAST, the way storing them yourself would.

Does an iframe really buy any security?

A malicious entity who seizes control of your page rendering could replace the javascript, sure. They could also replace the iframe loading code. I don't see why one would be any more or less of a risk than the other.

A full browser redirect will at least show a valid certificate in the URL bar and alert (savvy) users to shenanigans... assuming the user understands that "Stripe, Inc" is a legitimate payment service. Which they almost certainly don't, so the attacker just needs a (free, easy-to-obtain) certificate for any domain that looks plausible.

The underlying problem is that the trust model for credit card processing is fundamentally broken. There really aren't any rules - at least related to the technology for rendering a "type in your cc #" form - that can fix this.

The PCI-CSS self assessment strikes me as something that very few people filling out can really know definitively wether they are actually covered on everything on not.

Hence the requirement for a quarterly audit...

Thanks, I didn't understand that before. I'm looking for a hosted service to avoid as many of those things as possible!

Reply on news.ycombinator.com