3 ms·

Back up. I never transmitted any credit card details. All the inputs were heuristics about the end-user (ip address, GeoIP location, user-agent, referer, langua

Back up. I never transmitted any credit card details. All the inputs were heuristics about the end-user (ip address, GeoIP location, user-agent, referer, language, etc) or transaction meta-data (price, etc). Card number, expiration, CVV were NOT part of the inputs in Charge Control.

grecy 10y ago
> I never transmitted any credit card details. PCI compliance is only partially concerned with transmitting CC details, and is very much concerned with "YOU SHALL FOLLOW THE RULES". The rules say you are not allowed to do what you were doing. It's completely irrelevant if what you were doing is not a security or data transmission issue, it's simply against the rules. PCI compliance is an absolute nightmare, and is not something to be reasoned with, trust me. Logical thought and analysis has no place in PCI compliance. Follow the rules or else.
- smallnamespace 10y ago
  > Logical thought and analysis has no place in PCI compliance. Only at a local level. If you're writing standards that are going to be rolled out to the whole world and are difficult to change, and where the potential downside is people losing a lot of money, then a 'better safe than sorry' heuristic is the correct choice. Monkey-patching into your payments library at runtime certainly doesn't seem like a 'safe' practice that PCI ought to endorse at all. It's essentially impossible to write a standard that perfectly anticipates every edge case. And if it were possible, the list of rules would be even longer and more difficult to follow.
- ThatGeoGuy 10y ago
  I wonder if in part PCI compliance is designed this way as to avoid details or holes in the overall system from creeping up to the surface after years and years of usage and technologies evolving. I mean, sure, today he's just getting IP addresses, user-agents, and languages, but tomorrow we may be able to harvest something more, and in combination with what was given before, _just_the_credit_card_info on it's own isn't as valuable to an attacker as everything combined. Perhaps in it's own sick way, the rules as absolute is a design that prevents "feature"-creep from pushing its way into the PCI-compliance standards system. Maybe in limited circumstances we could adopt this sort of attitude to prevent feature-creep in other technologies from undermining the original intent of the work. I say this with full respect for the fact that in reality, if somebody tells me to "follow the rules" because "that's how it's done", I'm usually quite upset at their attitude about the whole thing.
  - misingnoglic 10y ago
    That's probably just an added benefit of their hugely bureaucratic system.
- nodesocket 10y ago
  I'd be curious if you can point to a specific section of PCI that states that a 3rd party cannot collect user meta-data. If that is true Google Analytics and Intercom could not track on checkout pages.
  - Artemis2 10y ago
    There is no such thing, but the standard dictates that all payment pages have to be served from a PCI DSS compliant environment. Stripe is in a very grey area, because they don't even have their merchants use iframes. Tampering with the script that (according to Stripe) makes the merchant compliant, and not being certified doing so, is a big no-no.
  - striking 10y ago
    I don't think it's a question of collecting user metadata or not. Here it really depends on "are the credit card details touching any non-PCI-compliant code?" Section 6.3.2 requires you to verify any "custom" code released to a customer that handles credit card information.[1] The way I see it, since your code touches that information, you must be PCI DSS compliant or you're breaking the chain of trust. 1: https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2.pdf?agreement=true&time=1477005719371#page=55 https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2.... (This is my opinion, which should be taken with a grain of salt.)
  - HillRat 10y ago
    A lot -- maybe most -- QSAs would absolutely flag an analytics script on a checkout page as a security issue, though they probably wouldn't consider it a pass/fail issue. PCI-DSS is a viral system, infecting every system that comes into contact with a covered environment. I've seen email servers and phone dialers get scoped in because they were used by employees handling payment card data.
- tzs 10y ago
  > PCI compliance is an absolute nightmare, and is not something to be reasoned with, trust me. Logical thought and analysis has no place in PCI compliance. Follow the rules or else. It's amazing how much of a pain it can be to deal with PCI, at least if you try to strictly follow the rules as written. For example, users will send email to support@yourcompany that says something like "I have a new credit card. Please update my subscription to bill using my VISA card 4111111111111434 with security code 123, expires 2020-03 instead of my current card, MasterCard 5111111111111506, security code 876, expires 2016-11. My account number is 123456. Thanks!". Of course that automatically generates a ticket in your ticket tracking system, and so now you've got a couple plain text credit card numbers (with CSCs!) in the ticket tracking database...which you never intended to store credit cards and have outside the PCI network's firewall. Is this a problem? It's a credit card number and it is stored on one of your servers, so one could certainly make a strong case that you need to get rid of it at the very least, and maybe you even need to have the ticket tracker inside the PCI network firewall and subject to all of the annoying PCI access restrictions. Ugh! And what if you are using a ticket tracker product that you don't host yourself? It's hosted on the vendor's servers. If a user sends in a credit card number in a support request, who is responsible for dealing with it? You, or the ticket tracker server provider? And it gets even worse. Suppose you've got anti-spam software running on your mail system. When that user mailed a credit card number to support@yourcompany, the anti-spam software saw the credit card number. It might now be stored in a token database for the anti-spam software's bayesian filters. How the heck are you supposed to deal with that? If you have any forums, they can also have this problem. Or if you have a company blog that allows users to comment. And what if you are outsourcing the comments to some place like Disqus? Then there is the problem of telephones. Customer calls your support line after hours, and leaves a message letting you know of their new credit card number, and giving the details. Oops...now you've got a stored credit card number in the saved recording of that customer's message. Does this mean your whole damned phone system has to be on the secure network and is in scope for PCI? (And what if you've outsourced your phone system?)
  - smallnamespace 10y ago
    Aren't the rules functioning properly in this case by identifying a real problem? Namely, that you shouldn't have credit card numbers inside an insecure system, whether a ticket tracker or an answering machine.
deleted 10y ago
[deleted]

grecy 10y ago

> I never transmitted any credit card details. PCI compliance is only partially concerned with transmitting CC details, and is very much concerned with "YOU SHALL FOLLOW THE RULES". The rules say you are not allowed to do what you were doing. It's completely irrelevant if what you were doing is not a security or data transmission issue, it's simply against the rules. PCI compliance is an absolute nightmare, and is not something to be reasoned with, trust me. Logical thought and analysis has no place in PCI compliance. Follow the rules or else.

smallnamespace 10y ago
> Logical thought and analysis has no place in PCI compliance. Only at a local level. If you're writing standards that are going to be rolled out to the whole world and are difficult to change, and where the potential downside is people losing a lot of money, then a 'better safe than sorry' heuristic is the correct choice. Monkey-patching into your payments library at runtime certainly doesn't seem like a 'safe' practice that PCI ought to endorse at all. It's essentially impossible to write a standard that perfectly anticipates every edge case. And if it were possible, the list of rules would be even longer and more difficult to follow.
ThatGeoGuy 10y ago
I wonder if in part PCI compliance is designed this way as to avoid details or holes in the overall system from creeping up to the surface after years and years of usage and technologies evolving. I mean, sure, today he's just getting IP addresses, user-agents, and languages, but tomorrow we may be able to harvest something more, and in combination with what was given before, _just_the_credit_card_info on it's own isn't as valuable to an attacker as everything combined. Perhaps in it's own sick way, the rules as absolute is a design that prevents "feature"-creep from pushing its way into the PCI-compliance standards system. Maybe in limited circumstances we could adopt this sort of attitude to prevent feature-creep in other technologies from undermining the original intent of the work. I say this with full respect for the fact that in reality, if somebody tells me to "follow the rules" because "that's how it's done", I'm usually quite upset at their attitude about the whole thing.
- misingnoglic 10y ago
  That's probably just an added benefit of their hugely bureaucratic system.
nodesocket 10y ago
I'd be curious if you can point to a specific section of PCI that states that a 3rd party cannot collect user meta-data. If that is true Google Analytics and Intercom could not track on checkout pages.
- Artemis2 10y ago
  There is no such thing, but the standard dictates that all payment pages have to be served from a PCI DSS compliant environment. Stripe is in a very grey area, because they don't even have their merchants use iframes. Tampering with the script that (according to Stripe) makes the merchant compliant, and not being certified doing so, is a big no-no.
- striking 10y ago
  I don't think it's a question of collecting user metadata or not. Here it really depends on "are the credit card details touching any non-PCI-compliant code?" Section 6.3.2 requires you to verify any "custom" code released to a customer that handles credit card information.[1] The way I see it, since your code touches that information, you must be PCI DSS compliant or you're breaking the chain of trust. 1: https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2.pdf?agreement=true&time=1477005719371#page=55 https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2.... (This is my opinion, which should be taken with a grain of salt.)
- HillRat 10y ago
  A lot -- maybe most -- QSAs would absolutely flag an analytics script on a checkout page as a security issue, though they probably wouldn't consider it a pass/fail issue. PCI-DSS is a viral system, infecting every system that comes into contact with a covered environment. I've seen email servers and phone dialers get scoped in because they were used by employees handling payment card data.
tzs 10y ago
> PCI compliance is an absolute nightmare, and is not something to be reasoned with, trust me. Logical thought and analysis has no place in PCI compliance. Follow the rules or else. It's amazing how much of a pain it can be to deal with PCI, at least if you try to strictly follow the rules as written. For example, users will send email to support@yourcompany that says something like "I have a new credit card. Please update my subscription to bill using my VISA card 4111111111111434 with security code 123, expires 2020-03 instead of my current card, MasterCard 5111111111111506, security code 876, expires 2016-11. My account number is 123456. Thanks!". Of course that automatically generates a ticket in your ticket tracking system, and so now you've got a couple plain text credit card numbers (with CSCs!) in the ticket tracking database...which you never intended to store credit cards and have outside the PCI network's firewall. Is this a problem? It's a credit card number and it is stored on one of your servers, so one could certainly make a strong case that you need to get rid of it at the very least, and maybe you even need to have the ticket tracker inside the PCI network firewall and subject to all of the annoying PCI access restrictions. Ugh! And what if you are using a ticket tracker product that you don't host yourself? It's hosted on the vendor's servers. If a user sends in a credit card number in a support request, who is responsible for dealing with it? You, or the ticket tracker server provider? And it gets even worse. Suppose you've got anti-spam software running on your mail system. When that user mailed a credit card number to support@yourcompany, the anti-spam software saw the credit card number. It might now be stored in a token database for the anti-spam software's bayesian filters. How the heck are you supposed to deal with that? If you have any forums, they can also have this problem. Or if you have a company blog that allows users to comment. And what if you are outsourcing the comments to some place like Disqus? Then there is the problem of telephones. Customer calls your support line after hours, and leaves a message letting you know of their new credit card number, and giving the details. Oops...now you've got a stored credit card number in the saved recording of that customer's message. Does this mean your whole damned phone system has to be on the secure network and is in scope for PCI? (And what if you've outsourced your phone system?)
- smallnamespace 10y ago
  Aren't the rules functioning properly in this case by identifying a real problem? Namely, that you shouldn't have credit card numbers inside an insecure system, whether a ticket tracker or an answering machine.

deleted 10y ago

[deleted]