5 ms·

I think you’re confusing what you’re supposed to do (according to PCI) vs. what you’re technically capable of doing. Look at the Stripe’s documentation for crea

by rcme 3y ago

I think you’re confusing what you’re supposed to do (according to PCI) vs. what you’re technically capable of doing. Look at the Stripe’s documentation for creating a payment method [0]. The parameters it takes are card number, expiration, and CVC. Any merchant using this API could trivially save the information for future, malicious use. 0: https://stripe.com/docs/api/payment_methods/create https://stripe.com/docs/api/payment_methods/create

Mordisquitos 3y ago
Please refer to the section just above, in the "Tokens" section. Emphasis is mine: > Tokenization is the process Stripe uses to collect sensitive card or bank account details, or personally identifiable information (PII), directly from your customers in a secure manner. A token representing this information is returned to your server to use. You should use our recommended payments integrations to perform this process client-side. This ensures that no sensitive card data touches your server, and allows your integration to operate in a PCI-compliant way. > If you cannot use client-side tokenization, you can also create tokens using the API with either your publishable or secret API key. Keep in mind that if your integration uses this method, you are responsible for any PCI compliance that may be required, and you must keep your secret API key safe. Unlike with client-side tokenization, your customer's information is not sent directly to Stripe, so we cannot determine how it is handled or stored. So in summary, yes, you can integrate with Stripe in such a way that you send them the card details... but then your business will need to be PCI compliant to the level of a PSP which, believe me, is damn hard. If you suspect that a merchant may go through the trouble of becoming PCI compliant only for the sake of being able to get customers card numbers for possible future malicious use, or do it in such a shoddy way that a malicious employee will be able to steal card numbers, you might as well just stop trusting online card payments in absolutely all cases, including Apple Pay.
- boringuser2 3y ago
  What point are you even making? Are you talking about trivial e-commerce transactions that you could make with Shopify? Yes, you could embed a payment gateway here. However, this is hardly universal or the norm. In an actual application, you're going to have some API layer over the processor you use. You don't store these credentials, but you do pass them over your API layer and could easily intercept them.
  - Mordisquitos 3y ago
    I'm making the point that I work in a department that develops a payment platform for a variety of retailers and has to perform non-trivial integrations with a broad range of PSPs worldwide, covering all sorts of payment flows, including cases in which the PSP itself has had to do new development on their end to cover use cases that they had never come across before. And yet, we do not at any point pass the card details through the API to the PSP. The input of all payment method data by the customer takes place either in PSP-hosted fields, on an iframe of the PSP front-end, or via a PSP-provided SDK or drop-in UI, in such a way that our software never sees the introduced data. All we see are the sanitised details (card type, BIN, and last 4 digits) that the PSP then sends to us.
- marcosdumay 3y ago
  You are insistently missing the point, and overlooking a series of security flaws just by reasoning that people aren't authorized to exploit them. I really hope that your job at that security provider is on marketing, because this is a hell of a bad mindset to work with security.
  - Mordisquitos 3y ago
    I don't think you have paid enough attention to detail when reading my comments to have an informed opinion as to whether I am "missing the point" or whether I am instead talking from in-depth practical experience on the subject.
    - tmpfile 3y ago
      You’re arguing that using a PCI compliant PSP solves the problem of credit card number harvesting, but that’s not correct unless the entire transaction takes place on the psp (like PayPal). Once the payment details are collected in environments outside the psp’s control, it’s not protected. For example, payment info could be skimmed by devs with access to payment pages using js like in the NewEgg Magecart attack
      - Mordisquitos 3y ago
        No, that is not what I am arguing. Please reread the thread.
        rcme 3y ago
        Here is a summary of your argument in your own words: > So in summary, yes, you can integrate with Stripe in such a way that you send them the card details... but then your business will need to be PCI compliant to the level of a PSP which, believe me, is damn hard. What others in this thread are arguing is that sharing CC details with anyone is a stupid way of doing payments. It doesn't matter if you're interacting with a PSP or otherwise. You shouldn't share a secret that someone else could use to generate payments. You should share some type of payload that is only valid for the payment you're making.

by rcme 3y ago

Mordisquitos 3y ago

Please refer to the section just above, in the "Tokens" section. Emphasis is mine: > Tokenization is the process Stripe uses to collect sensitive card or bank account details, or personally identifiable information (PII), directly from your customers in a secure manner. A token representing this information is returned to your server to use. You should use our recommended payments integrations to perform this process client-side. This ensures that no sensitive card data touches your server, and allows your integration to operate in a PCI-compliant way. > If you cannot use client-side tokenization, you can also create tokens using the API with either your publishable or secret API key. Keep in mind that if your integration uses this method, you are responsible for any PCI compliance that may be required, and you must keep your secret API key safe. Unlike with client-side tokenization, your customer's information is not sent directly to Stripe, so we cannot determine how it is handled or stored. So in summary, yes, you can integrate with Stripe in such a way that you send them the card details... but then your business will need to be PCI compliant to the level of a PSP which, believe me, is damn hard. If you suspect that a merchant may go through the trouble of becoming PCI compliant only for the sake of being able to get customers card numbers for possible future malicious use, or do it in such a shoddy way that a malicious employee will be able to steal card numbers, you might as well just stop trusting online card payments in absolutely all cases, including Apple Pay.

boringuser2 3y ago
What point are you even making? Are you talking about trivial e-commerce transactions that you could make with Shopify? Yes, you could embed a payment gateway here. However, this is hardly universal or the norm. In an actual application, you're going to have some API layer over the processor you use. You don't store these credentials, but you do pass them over your API layer and could easily intercept them.
- Mordisquitos 3y ago
  I'm making the point that I work in a department that develops a payment platform for a variety of retailers and has to perform non-trivial integrations with a broad range of PSPs worldwide, covering all sorts of payment flows, including cases in which the PSP itself has had to do new development on their end to cover use cases that they had never come across before. And yet, we do not at any point pass the card details through the API to the PSP. The input of all payment method data by the customer takes place either in PSP-hosted fields, on an iframe of the PSP front-end, or via a PSP-provided SDK or drop-in UI, in such a way that our software never sees the introduced data. All we see are the sanitised details (card type, BIN, and last 4 digits) that the PSP then sends to us.
marcosdumay 3y ago
You are insistently missing the point, and overlooking a series of security flaws just by reasoning that people aren't authorized to exploit them. I really hope that your job at that security provider is on marketing, because this is a hell of a bad mindset to work with security.
- Mordisquitos 3y ago
  I don't think you have paid enough attention to detail when reading my comments to have an informed opinion as to whether I am "missing the point" or whether I am instead talking from in-depth practical experience on the subject.
  - tmpfile 3y ago
    You’re arguing that using a PCI compliant PSP solves the problem of credit card number harvesting, but that’s not correct unless the entire transaction takes place on the psp (like PayPal). Once the payment details are collected in environments outside the psp’s control, it’s not protected. For example, payment info could be skimmed by devs with access to payment pages using js like in the NewEgg Magecart attack
    - Mordisquitos 3y ago
      No, that is not what I am arguing. Please reread the thread.
      - rcme 3y ago
        Here is a summary of your argument in your own words: > So in summary, yes, you can integrate with Stripe in such a way that you send them the card details... but then your business will need to be PCI compliant to the level of a PSP which, believe me, is damn hard. What others in this thread are arguing is that sharing CC details with anyone is a stupid way of doing payments. It doesn't matter if you're interacting with a PSP or otherwise. You shouldn't share a secret that someone else could use to generate payments. You should share some type of payload that is only valid for the payment you're making.