Stripe Payment Gateway - Pci Compliance?

[MemoryX2]

I'm certainly keeping a very close eye on this thread..

I have been using stripe so I'm not very sure what to do now. I, like everyone else didn't realize tokenized transmission wasn't supported.

[velaware]

I'm certainly keeping a very close eye on this thread..

I have been using stripe so I'm not very sure what to do now. I, like everyone else didn't realize tokenized transmission wasn't supported.

It is and isn't.

 

Blesta's Stripe module tokenizes data, but it doesn't do it in a fashion that it should so people are compliant w/t PCI level 3 & 4 (which requires that no card data whatsoever is to touch the server).  This is why the JavaScript libraries are made by such providers, so that people can write code with JavaScript (which runs in the browser thus never having to touch the server) to tokenize data, and then the JavaScript just sends the tokenized data to the server.

 

Blesta's Stripe sends the card data to the Stripe's server which then tokenizes it on their end.  So, the whole "don't let Blesta store card data and instead let Stripe store it" feature works and is accurate, because you don't store the card data in Blesta's database, but it doesn't solve the PCI compliance issue because you're still directly sending card data to the server Blesta is on.  That's the point I was trying to make to Cody but I was also cooking dinner so I may have not got that across properly.

[Cody]

Just to clarify, you're saying having card data be passed through Blesta (which is stored on a seller's server) doesn't violate PCI even if the data isn't stored?

 

Not trying to be a dick, just wanting to verify/clarify this.

 

Correct. PCI compliance is nothing more than a set of guidelines describing HOW to store and handle card information securely. Blesta follow those guidelines. So if your server is properly configured you are already PCI compliant.

 

The discussion regarding never touching card data (using stripe.js, etc.) is PCI avoidance, not compliance. If you never touch card details you don't have to worry about PCI compliance.

[Cody]

It is and isn't.

 

Blesta's Stripe module tokenizes data, but it doesn't do it in a fashion that it should so people are compliant w/t PCI level 3 & 4 (which requires that no card data whatsoever is to touch the server).

 

Where are you getting this bizarre information? It's certainly not from the PCI spec. If the server doesn't touch the card data there is no need for PCI!

[iamp]

Correct. PCI compliance is nothing more than a set of guidelines describing HOW to store and handle card information securely. Blesta follow those guidelines. So if your server is properly configured you are already PCI compliant.

 

The discussion regarding never touching card data (using stripe.js, etc.) is PCI avoidance, not compliance. If you never touch card details you don't have to worry about PCI compliance.

 

Server is properly configured -> PCI compliance. 

 

My issue is that there is nothing that makes it clear to users that Blesta's Stripe integration doesn't support full no-contact with card details. As a result, there will be people (like I almost did, and like others on this post) who are preparing to or have already implemented this in live environments without filling out the necessary PCI questionnaire (which you can avoid if you don't touch the details) and without any idea that their regular hosting environments aren't good enough for it. That is where the compliance rules are being broken, and people are becoming liable for fines. These people need to know the exact spec of the plugin so they can make informed decisions about how to use it.

[Paul]

I predict that in the future, stripe.js and other javascript implementations will no longer be exempt from PCI. While the card details technically don't touch the server, the server is responsible for serving the markup. An attacker with access to the server could modify the javascript in order to intercept those details.

[velaware]

I predict that in the future, stripe.js and other javascript implementations will no longer be exempt from PCI. While the card details technically don't touch the server, the server is responsible for serving the markup. An attacker with access to the server could modify the javascript in order to intercept those details.

The whole purpose of Stripe.js and such is to allow users to store card data without having to meet PCI level 1 & 2 compliance, not to do PCI avoidance.  It lets you offload the storage security requirements and worry about managing your systems.

 

https://www.pcisecuritystandards.org/documents/SAQ_D_v3_ServiceProvider.pdf document page 17 (real page 23) starts the questionaire portion of data retention and storage.  This document provides the bare minimum required to be PCI compliant (level 4).

 

The JavaScript libraries aren't really exempt from PCI, its just that they allow the provider to meet PCI requirements without having to follow level 1 & 2 guidelines themselves, and it also makes meeting level 3 & 4 a lot easier as well.  Which, poses another risk, but its one people take regardless.

[Paul]

The whole purpose of Stripe.js and such is to allow users to store card data without having to meet PCI level 1 & 2 compliance, not to do PCI avoidance.  It lets you offload the storage security requirements and worry about managing your systems.

 

https://www.pcisecuritystandards.org/documents/SAQ_D_v3_ServiceProvider.pdf document page 17 (real page 23) starts the questionaire portion of data retention and storage.  This document provides the bare minimum required to be PCI compliant (level 4).

 

The JavaScript libraries aren't really exempt from PCI, its just that they allow the provider to meet PCI requirements without having to follow level 1 & 2 guidelines themselves, and it also makes meeting level 3 & 4 a lot easier as well.  Which, poses another risk, but its one people take regardless.

 

Maybe you can clarify PCI levels.

 

I understand PCI Level 1, 2, 3, 4 to be largely based on transaction volume. See http://usa.visa.com/merchants/protect-your-business/cisp/merchant-pci-dss-compliance.jsp. Levels 2-4 require the annual SAQ and quarterly network scan. Is this what you mean?

 

If you are a Level 4 merchant, based on your transaction volume, you still have to fill out the SAQ, and get a quarterly network scan.

 

I think the question is, what exactly is the difference in terms of what you have to do by using stripe.js versus passing the data through without storage. If all merchants must fill out the SAQ, and get a quarterly network scan for PCI compliance, and using stripe.js does not exempt you from these requirements, what is the difference?

[iamp]

I think we're missing the point here: there are a potentially high number of people using this plugin thinking that it doesn't contact the card numbers at all, when it actually does. These people need to be informed of this so they can make informed decisions about what to do next - be it PCI compliance or a plugin / gateway / software change. 

[Cody]

I think we're missing the point here: there are a potentially high number of people using this plugin thinking that it doesn't contact the card numbers at all, when it actually does. These people need to be informed of this so they can make informed decisions about what to do next - be it PCI compliance or a plugin / gateway / software change. 

 

Does Stripe not do this? Last time I checked they did.

[velaware]

Maybe you can clarify PCI levels.

 

I understand PCI Level 1, 2, 3, 4 to be largely based on transaction volume. See http://usa.visa.com/merchants/protect-your-business/cisp/merchant-pci-dss-compliance.jsp. Levels 2-4 require the annual SAQ and quarterly network scan. Is this what you mean?

 

If you are a Level 4 merchant, based on your transaction volume, you still have to fill out the SAQ, and get a quarterly network scan.

 

I think the question is, what exactly is the difference in terms of what you have to do by using stripe.js versus passing the data through without storage. If all merchants must fill out the SAQ, and get a quarterly network scan for PCI compliance, and using stripe.js does not exempt you from these requirements, what is the difference?

I know PCI level 1 is more towards those who do 4 mil. + transactions, not sure on the others as I'm not a banker or someone heavily involved in it.  I've never been aware of a transaction class for them, though, just more so what you intend to do with the data.

 

What Stripe.js does is send the card data directly from the browser to Stripe's servers, without the server Blesta is installed on ever seeing that.  It then returns a token/hash of the data that Blesta can store in the database without ever knowing what the card data is.  This is why Stripe created the JS library, so that it's client->server instead of client->server->server.  From my previous experience, once any bit of card data (last 4, cvv, etc...) touches the server that Blesta is on, it has to conform to PCI regulations, because its still sensitive information.

 

Blesta still stores some data.  IF the data is encrypted, then it helps tremendously, but that requires that the last 4, cvv, address, etc...(whatever it stores) is encrypted.  But, with how Blesta works now, that data in its completeness is still passed to Blesta, which means now the user has to at least conform to level 4 or 3.

 

Yes, network scans and such are still required even at level 4, though they are not as intrusive so to speak (takes a lot less to do than say a level 1 scan).

 

The whole argument here, and what has I believe been presented before, is that Blesta sees the card data (full PAN, CVV, etc...).  Even if Blesta doesn't store it all, it still stores some and thus needs to comply with PCI.  Using something like Stripe.js changes that so Blesta doesn't have to concern itself with meeting PCI and it can just store a token that it can then pass to Stripe and Stripe can map it to card data.

 

Basically any servers that see card data need to comply to PCI.  A token isn't card data.  You can still retrieve the last 4 and all that via the token.  It just takes an API call.

[Ken]

This would make a good feature request. 

[Max]

This is untrue and misleading. Blesta is entirely PCI compliant, regardless of how you choose to store or not store card details. The only compliance requirement which must be followed (and is entirely outside of Blesta's control) is PCI compliance scans to ensure proper server configuration.

 

Server sounds singular.

As mentioned before, you need at least a separate database server in a private network if you store card holder data.

 

Or you will already be not in compliance with "1.3.7 Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks."

Where cardholder data is defined as any of the following: "PAN, Cardholder Name, Service Code, Expiration Date"

 

Note that your quarterly security scan will not test for things like this.

Having the scan is one of the requirements, not proof that you meet other requirements.

 

 

You are right that being PCI compliant is the user's responsibility, and not Blesta though.

But perhaps that could be made more clear by adding a message reminding the user of the need for that, on the merchant gateway installation pages.

And that -while they may look less pretty- non-merchant gateways may be a better solution for those that prefer not to jump through all the PCI hoops.

[velaware]

You are right that being PCI compliant is the user's responsibility, and not Blesta though.

It is Blesta's responsibility to the degree of what it can do.  Blesta isn't responsible for having proper accounts/software installed and configured, but it is responsible for how it stores and handle CC data.

[Cody]

Server sounds singular.

 

"Servers" would not have been correct grammar.

[iamp]

Does Stripe not do this? Last time I checked they did.

 

Do what, exactly? 

[xison]

Server sounds singular.

As mentioned before, you need at least a separate database server in a private network if you store card holder data.

Or you will already be not in compliance with "1.3.7 Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks."

Where cardholder data is defined as any of the following: "PAN, Cardholder Name, Service Code, Expiration Date"

Note that your quarterly security scan will not test for things like this.

Having the scan is one of the requirements, not proof that you meet other requirements.

I think this is being overlooked here, buy Blesta itself does not store the card data at all when used in conjunction with Stripe. No, it does not use Stripe.js (yet).

Provided your server is properly serving up through an SSL/TLS connection, its fine. Transmission is fine, as long as its encrypted.

What Blesta does store, is the Stripe token in which future transactions are processed with.

Perhaps the devs can explain more indepth but from my own personal knowledge they are completely in the clear provided the user of Blesta properly secures their servers and all connections involving card data is encrypted.

[Max]

What Blesta does store, is the Stripe token in which future transactions are processed with.

 

Only the token? Or token + expiration date?

Note that the expiration date is considered cardholder data as well.

[Ken]

Only the token? Or token + expiration date?

Note that the expiration date is considered cardholder data as well.

 

Not according to this:  "Creates a single use token that wraps the details of a credit card."

 

Edit:  but then as I look in my database I can see that the last four and exp are encrypted but regardless populated.  So I see what you mean.

[Max]

Not according to this:  "Creates a single use token that wraps the details of a credit card."

 

Single use tokens are the Stripe.js thing Blesta is not using...

 

The tokens Blesta uses are multiple use, and is the customer id returned by Stripe_Customer::create().

It stores those tokens in combination with the card holder name, expiration date and last4.

[Ken]

That's the Stripe.js thing Blesta is not using...

 

I saw and edited a bit late I guess.  So this doesn't even qualify for PCI avoidance which is why people want to use it so I agree with iamp. Paul is right though about stripe.js and the server handling the markup, always kind of wondered about that myself.

[Max]

Paul is right though about stripe.js and the server handling the markup, always kind of wondered about that myself.

 

Also agree with that.

Other payment service providers have been getting away with similar tricks for a long time though, so it will probably last.

 

E.g. authorize.net offers one where you create and host the form on your own server, but let it point to their servers ( <form method="post" action="https://server-provided-by-gateway/"> ), and then redirects the customer back to your server straight away.

While it is true that the card details then normally do not touch your server, it still means that if your server is compromised the details can be directed elsewhere.

[Virtovo]

Also agree with that.

Other payment service providers have been getting away with similar tricks for a long time though, so it will probably last.

 

E.g. authorize.net offers one where you create and host the form on your own server, but let it point to their servers ( <form method="post" action="https://server-provided-by-gateway/"> ), and then redirects the customer back to your server straight away.

While it is true that the card details then normally do not touch your server, it still means that if your server is compromised the details can be directed elsewhere.

 

It's like all these companies that offer login via https post on http page.  It's fine that you post via https, but how do I know the page I am on is not compromised already?

[Ken]

It's like all these companies that offer login via https post on http page.  It's fine that you post via https, but how do I know the page I am on is not compromised already?

 

Make sure your merchant is PCI compliant.  

[Mdhsmith]

I must admit I am shocked this is not clearly stated on the main pages of Blesta's website. I've just spent 2 hours looking through features and comparing Blesta with WHMCS and I was so close to making the switch until I discovered this thread.

Having the choice to use Stripe.js is a must have feature I am afraid.

I hope you can implement this change ASAP and rescue lots of unsuspecting users.