5 ms·

Instead of just down voting this post, it would be helpful to know what specific parts of it are incorrect. This is the first I've heard of these objections.

by JunkDNA 13y ago

pbreit 13y ago
I think the downvotes have to do with what is a pretty serious accusation and not apparently backed up with facts. What would be helpful is if the accuser produced a better description of what he feels is out of compliance, wrong or misleading.
- patcheudor 13y ago
  Because the PCI guidance isn't factual enough? An essay could be written about the problems with broad statements like merchants only needing to worry about the inclusion of Stripe.JS and the use of HTTPS to be PCI compliant. Luckily those already exist. This one covers it pretty well: http://pciguru.wordpress.com/2013/06/30/developers-beware-stripe/ http://pciguru.wordpress.com/2013/06/30/developers-beware-st...
  - ricardobeat 13y ago
    That article is wrong on the technical implications, like "It may be their code, but it is executing on your server" (cc data is sent directly to Stripe's servers, never touching your own).
    - patcheudor 13y ago
      That was maybe not quite the right language, but is easily salvageable. What the author was trying to convey is that the Stripe.js code is instantiated within the user browser by an HTTP response from the server infrastructure owned by the merchant. The actual credit-card form is delivered by the merchants server & therefore they own all the PCI DSS related controls surrounding ensuring that the payment form code delivered via their HTTP response is secured. If instead of referencing Stripe.js, the merchant instead sent the user directly to https://stripe.com/payment.. https://stripe.com/payment... and the user could validate they are at stripe.com by looking in their address bar & checking the SSL/TLS security by clicking on the lock then that's a different story and the merchant would have far less exposure to the requirements outlined in the PCI DSS.
      - slexaxton 13y ago
        [Stripe Developer] [edited for clarification] I appreciate your interest in the security of Stripe, I think we definitely share the same goals here (making everything as secure as possible). However, I think there's some misunderstanding in some posts (and in the blog post): > [...] the Stripe.js code is instantiated within the user browser by an HTTP response from the server infrastructure owned by the merchant When Stripe.js is included within the user's browser by a (mandated https, not http) request, it comes directly from Stripe's servers, not from "the server infrastructure owned by the merchant." Stripe.js isn't served from the merchant. It comes directly from Stripe. Stripe.js helps keep payment card data away from a merchants own servers. Keeping card data away from someone's machines doesn't mean that they don't need to comply with the Payment Card Industry Data Security Standards, but it does make things quite a bit simpler. In most cases it means that they're eligible for one of the light-weight self-assessment questionnaires. PCI compliance, of course, shouldn't be where people stop thinking about security though. You're absolutely right that if the pointer on the merchant's site is changed to a malicious site, that's where the payment data will go. The merchant needs to keep that pointer safe in the same way that if you're redirecting to a hosted payment form or elsewhere, you need to make sure that isn't tampered with either. (A hosted form has the advantage that at least a customer can view the SSL cert but if they don't recognize the domain (or if the domain is obscure anyway), that's not much good.) Being compliant with the PCI standards is important but it doesn't cover all of the very, very important points of web security. We do take security very seriously, and if you happen to find a valid security issue with our service, we pay bounties[1] for properly disclosed vulnerabilities. If you have any other questions, or would like to wax poetic about security or PCI please don't hesitate to send the security team an email at security@stripe.com or to email me personally at alex@stripe.com. [1] https://stripe.com/help/security#rewards https://stripe.com/help/security#rewards
        steven2012 13y ago
        My understanding by reading patcheudor's responses is that the issue isn't with Stripe's PCI compliance, but rather the fact that merchants that use Stripe's API need to be fully PCI compliant. According to him, using Stripe's API doesn't obviate the merchant's need to be fully PCI compliant, unless they do something like open up another window where the URL clearly shows that they are inputting a form from Stripe's own servers. Otherwise, the merchant needs to conform to full PCI compliance.
  - pbreit 13y ago
    I read that and am still far from clear on whether or not your accusations have merit.
    - patcheudor 13y ago
      I think you just hit on a major issue that merchants face when it comes to the PCI DSS. Many merchants have been wrestling with the scope of PCI DSS compliance for years. They are looking for easy solutions where unfortunately there are very few. The PCI council has done a very respectable job of creating compliance guides and standards documentation. However, when it comes to implementation merchants struggle with scope. If a merchant server as an example responds with a reference to the stripe.js & that code is then executed within the browser context of the merchant domain, is that merchant server in scope for that component? I believe it is and every QSA (PCI qualified security assessor) I've had this same conversation with has come to that exact same conclusion. If Stripe consults with their QSA and they come to a different conclusion, then I would hope Stripe would share that publicly with the community. That would certainly be a ground breaking event for those of us who deal with PCI DSS on a daily basis. In terms of accusation, my goal here is to ensure that Stripe.com and others who are working in this space are being as clear as possible with their communication, that's it. Stripe is going to address statements like the one I pointed out on their site & hopefully as an industry we can get to a point where everyone is a bit more clear on what falls in and out of PCI DSS scope.
deleted 13y ago
[deleted]
Silhouette 13y ago
These posts are probably being downvoted because they come from a new account, which has been attacking Stripe repeatedly in multiple discussions now, including making some assumptions/claims that are readily confirmed to be false (and are obviously so to anyone who's actually integrated Stripe) and citing supporting web pages that don't necessarily support the claims made. While the PCI compliance issue may not be quite as simple as Stripe's documentation has previously implied, nobody else seems to be able to identify the kinds of serious compliance issues that patcheudor keeps implying we're all suffering from by using Stripe and following their existing advice.
- patcheudor 13y ago
  I am simply pointing out that unlike what is covered in the Stripe documentation, a merchant is not absolved of PCI compliance by simply implementing Stripe.js in their HTTP response & turning on SSL/TLS. The PCI DSS and related materials cover this fact quite well. This "dispute" if you could even call it that came about when Pete Keen inadvertently also over simplified the compliance issue in one of his posts, for which he has since rectified: https://www.petekeen.net/life-of-a-stripe-charge https://www.petekeen.net/life-of-a-stripe-charge Subsequent discussion here: https://news.ycombinator.com/item?id=7091788 https://news.ycombinator.com/item?id=7091788

Instead of just down voting this post, it would be helpful to know what specific parts of it are incorrect. This is the first I've heard of these objections.

by JunkDNA 13y ago

Instead of just down voting this post, it would be helpful to know what specific parts of it are incorrect. This is the first I've heard of these objections.

pbreit 13y ago

I think the downvotes have to do with what is a pretty serious accusation and not apparently backed up with facts. What would be helpful is if the accuser produced a better description of what he feels is out of compliance, wrong or misleading.

patcheudor 13y ago
Because the PCI guidance isn't factual enough? An essay could be written about the problems with broad statements like merchants only needing to worry about the inclusion of Stripe.JS and the use of HTTPS to be PCI compliant. Luckily those already exist. This one covers it pretty well: http://pciguru.wordpress.com/2013/06/30/developers-beware-stripe/ http://pciguru.wordpress.com/2013/06/30/developers-beware-st...
- ricardobeat 13y ago
  That article is wrong on the technical implications, like "It may be their code, but it is executing on your server" (cc data is sent directly to Stripe's servers, never touching your own).
  - patcheudor 13y ago
    That was maybe not quite the right language, but is easily salvageable. What the author was trying to convey is that the Stripe.js code is instantiated within the user browser by an HTTP response from the server infrastructure owned by the merchant. The actual credit-card form is delivered by the merchants server & therefore they own all the PCI DSS related controls surrounding ensuring that the payment form code delivered via their HTTP response is secured. If instead of referencing Stripe.js, the merchant instead sent the user directly to https://stripe.com/payment.. https://stripe.com/payment... and the user could validate they are at stripe.com by looking in their address bar & checking the SSL/TLS security by clicking on the lock then that's a different story and the merchant would have far less exposure to the requirements outlined in the PCI DSS.
    - slexaxton 13y ago
      [Stripe Developer] [edited for clarification] I appreciate your interest in the security of Stripe, I think we definitely share the same goals here (making everything as secure as possible). However, I think there's some misunderstanding in some posts (and in the blog post): > [...] the Stripe.js code is instantiated within the user browser by an HTTP response from the server infrastructure owned by the merchant When Stripe.js is included within the user's browser by a (mandated https, not http) request, it comes directly from Stripe's servers, not from "the server infrastructure owned by the merchant." Stripe.js isn't served from the merchant. It comes directly from Stripe. Stripe.js helps keep payment card data away from a merchants own servers. Keeping card data away from someone's machines doesn't mean that they don't need to comply with the Payment Card Industry Data Security Standards, but it does make things quite a bit simpler. In most cases it means that they're eligible for one of the light-weight self-assessment questionnaires. PCI compliance, of course, shouldn't be where people stop thinking about security though. You're absolutely right that if the pointer on the merchant's site is changed to a malicious site, that's where the payment data will go. The merchant needs to keep that pointer safe in the same way that if you're redirecting to a hosted payment form or elsewhere, you need to make sure that isn't tampered with either. (A hosted form has the advantage that at least a customer can view the SSL cert but if they don't recognize the domain (or if the domain is obscure anyway), that's not much good.) Being compliant with the PCI standards is important but it doesn't cover all of the very, very important points of web security. We do take security very seriously, and if you happen to find a valid security issue with our service, we pay bounties[1] for properly disclosed vulnerabilities. If you have any other questions, or would like to wax poetic about security or PCI please don't hesitate to send the security team an email at security@stripe.com or to email me personally at alex@stripe.com. [1] https://stripe.com/help/security#rewards https://stripe.com/help/security#rewards
      - steven2012 13y ago
        My understanding by reading patcheudor's responses is that the issue isn't with Stripe's PCI compliance, but rather the fact that merchants that use Stripe's API need to be fully PCI compliant. According to him, using Stripe's API doesn't obviate the merchant's need to be fully PCI compliant, unless they do something like open up another window where the URL clearly shows that they are inputting a form from Stripe's own servers. Otherwise, the merchant needs to conform to full PCI compliance.
- pbreit 13y ago
  I read that and am still far from clear on whether or not your accusations have merit.
  - patcheudor 13y ago
    I think you just hit on a major issue that merchants face when it comes to the PCI DSS. Many merchants have been wrestling with the scope of PCI DSS compliance for years. They are looking for easy solutions where unfortunately there are very few. The PCI council has done a very respectable job of creating compliance guides and standards documentation. However, when it comes to implementation merchants struggle with scope. If a merchant server as an example responds with a reference to the stripe.js & that code is then executed within the browser context of the merchant domain, is that merchant server in scope for that component? I believe it is and every QSA (PCI qualified security assessor) I've had this same conversation with has come to that exact same conclusion. If Stripe consults with their QSA and they come to a different conclusion, then I would hope Stripe would share that publicly with the community. That would certainly be a ground breaking event for those of us who deal with PCI DSS on a daily basis. In terms of accusation, my goal here is to ensure that Stripe.com and others who are working in this space are being as clear as possible with their communication, that's it. Stripe is going to address statements like the one I pointed out on their site & hopefully as an industry we can get to a point where everyone is a bit more clear on what falls in and out of PCI DSS scope.

deleted 13y ago

[deleted]

Silhouette 13y ago

These posts are probably being downvoted because they come from a new account, which has been attacking Stripe repeatedly in multiple discussions now, including making some assumptions/claims that are readily confirmed to be false (and are obviously so to anyone who's actually integrated Stripe) and citing supporting web pages that don't necessarily support the claims made. While the PCI compliance issue may not be quite as simple as Stripe's documentation has previously implied, nobody else seems to be able to identify the kinds of serious compliance issues that patcheudor keeps implying we're all suffering from by using Stripe and following their existing advice.

patcheudor 13y ago
I am simply pointing out that unlike what is covered in the Stripe documentation, a merchant is not absolved of PCI compliance by simply implementing Stripe.js in their HTTP response & turning on SSL/TLS. The PCI DSS and related materials cover this fact quite well. This "dispute" if you could even call it that came about when Pete Keen inadvertently also over simplified the compliance issue in one of his posts, for which he has since rectified: https://www.petekeen.net/life-of-a-stripe-charge https://www.petekeen.net/life-of-a-stripe-charge Subsequent discussion here: https://news.ycombinator.com/item?id=7091788 https://news.ycombinator.com/item?id=7091788