Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Life of a Stripe Charge

petekeen.net

Post reply on HN
Print view View original

11–20 of 37 posts

Re: The Life of a Stripe Charge

#11

Post by Silhouette »

patcheudor wrote: post #10
Silhouette wrote: post #8

Earlier quoted context omitted.

If the PCI guys really want small businesses to be careful around tokenization, one might suggest that publishing yet another very long document about technicalities is rather self-defeating. It's the new generation of payment services like Stripe that are offering out-of-the-box forms and vaults and tokenization and so on. These services are doing well precisely because they manage to make the card payment industry…

The problem is when companies like Stripe provide misleading or patently false guidance in order to build their business. It's very amazing when people buy-into the idea of completely side-stepping PCI by implementing SSL & some Javascript within their same origin.

Where did this same origin fixation you have come from? You keep mentioning it, but stripe.js or checkout.js would normally be loaded directly from a subdomain of stripe.com over HTTPS, and the pages that load that JS, which really are coming from the vendor's own domain, are also required to be served via HTTPS according to Stripe's guidance.

To compromise that set-up without compromising the communications infrastructure or Stripe itself, an attacker would need to be able to modify the files served from the vendor's system. Anyone who can do that can just as easily serve a page that puts a form up asking for card details but then simply e-mails anything submitted to the accountant of their favourite Nigerian prince, never going anywhere near Stripe. So what is it you're concerned about here and how do you think anything in PCI DSS actually makes it better?

Re: The Life of a Stripe Charge

#12

Post by [deleted] »

patcheudor wrote: post #7
zrail wrote: post #6

Earlier quoted context omitted.

According to Stripe themselves, no. Honestly most of PCI is common-sense stuff that you should be doing anyway (firewalls, restricting access, etc) but the compliance audits are strictly optional with Stripe as long as you're serving over HTTPS and are using their tokenizing javascript.

Then Stripe might want to reconsider their guidance in light of the PCI guidance on tokenization. Reference: "2.4.2 Merchant Responsibilities" https://www.pcisecuritystandards.org/documents/Tokenization_... The only way out of being responsible for PCI compliance would be to offload the entire transaction to the payment provider. This means sending the customer entirely off domain of the merchant (iFrames don't get y…

[deleted]

Re: The Life of a Stripe Charge

#13

Post by pbreit »

patcheudor wrote: post #7
zrail wrote: post #6

Earlier quoted context omitted.

According to Stripe themselves, no. Honestly most of PCI is common-sense stuff that you should be doing anyway (firewalls, restricting access, etc) but the compliance audits are strictly optional with Stripe as long as you're serving over HTTPS and are using their tokenizing javascript.

Then Stripe might want to reconsider their guidance in light of the PCI guidance on tokenization. Reference: "2.4.2 Merchant Responsibilities" https://www.pcisecuritystandards.org/documents/Tokenization_... The only way out of being responsible for PCI compliance would be to offload the entire transaction to the payment provider. This means sending the customer entirely off domain of the merchant (iFrames don't get y…

After reading the doc and paying close attention to that section, it's not clear to me what the Stripe problem is. I didn't see anywhere that the Stripe approach would not comply.

Re: The Life of a Stripe Charge

#14

Post by pbreit »

patcheudor wrote: post #10
Silhouette wrote: post #8

Earlier quoted context omitted.

If the PCI guys really want small businesses to be careful around tokenization, one might suggest that publishing yet another very long document about technicalities is rather self-defeating. It's the new generation of payment services like Stripe that are offering out-of-the-box forms and vaults and tokenization and so on. These services are doing well precisely because they manage to make the card payment industry…

The problem is when companies like Stripe provide misleading or patently false guidance in order to build their business. It's very amazing when people buy-into the idea of completely side-stepping PCI by implementing SSL & some Javascript within their same origin.

If you're going to accuse a leading provider of "misleading or false guidance" you need to provide some evidence.

Re: The Life of a Stripe Charge

#15

Post by pixl97 »

patcheudor wrote: post #9
zrail wrote: post #6

Earlier quoted context omitted.

According to Stripe themselves, no. Honestly most of PCI is common-sense stuff that you should be doing anyway (firewalls, restricting access, etc) but the compliance audits are strictly optional with Stripe as long as you're serving over HTTPS and are using their tokenizing javascript.

Wow, I just checked their guidance & they absolutely need to reconsider their guidance: "Do I need to be PCI compliant? What do I have to do? Anyone accepting credit card payments must be PCI compliant—but with Stripe, it's easy: Serve your payment page over SSL, i.e., the page's web address should begin with "https", not "http". Use Stripe.js as the only means by which you accept payment information and transmit it…

Just over 'SSL' itself isn't enough, even if it was enough. There are so many broken configurations and weak ciphers that just having a lock on your url bar isn't enough.

https://www.ssllabs.com/ssltest/index.html

Re: The Life of a Stripe Charge

#16

Post by krat0sprakhar »

We're an ecommerce company who have been dealing with the baggage of "1-click buy" that we implemented a year back. To persist the cards we had to build our own infrastructure thereby increasing our PCI exposure. The yearly audits, honestly, are costing us a fortune. I need to make a business case around getting rid of the card related infrastructure and using some third party that provides tokenization-as-a-service. Are there any vendors out there who do that?

After doing this,will my PCI exposure reduce significantly? As long as my customers are entering their CC details over the vendor's secure page and I'm making encrypted API calls to their service on HTTPS pages (like Stripe) do I still need to get PCI Certified?

Re: The Life of a Stripe Charge

#17

Post by MarkMc »

I don't understand why Stripe needs to know my customer's credit card number.

Wouldn't it improve security if my web page encrypted the credit card number using Mastercard's public key before sending it to Stripe?

Re: The Life of a Stripe Charge

#18

Post by patcheudor »

pbreit wrote: post #14
patcheudor wrote: post #10

Earlier quoted context omitted.

The problem is when companies like Stripe provide misleading or patently false guidance in order to build their business. It's very amazing when people buy-into the idea of completely side-stepping PCI by implementing SSL & some Javascript within their same origin.

If you're going to accuse a leading provider of "misleading or false guidance" you need to provide some evidence.

The PCI council has already provided the evidence for which I've already provided the link. Read the PCI guidance surrounding tokenization. It makes it very clear. Just think about this rationally for a second. If you are a merchant who uses a bit of JavaScript provided by a payment provider and customers enter their credit-card information into the form created by that JavaScript, but instantiated by an HTTP response from the same origin of your domain how do you as a merchant side-step responsibility for PCI compliance? The simple fact of the matter and as outlined in the latest PCI guidance, you don't. Now if you instead send your customer directly to Stripe and they collect the credit card information within their same origin, then yes, PCI side-stepped. Stripe and any other vendor in this space need to behave responsibly and ensure their customers understand their PCI responsibilities.

Re: The Life of a Stripe Charge

#19

Post by superuser2 »

MarkMc wrote: post #17

I don't understand why Stripe needs to know my customer's credit card number. Wouldn't it improve security if my web page encrypted the credit card number using Mastercard's public key before sending it to Stripe?

If services like Stripe accepted already-encrypted credit card numbers, couldn't someone just steal the already-encrypted credit card numbers and run them through Stripe?

Also, resting the security of the payment infrastructure on a single keypair (per network) seems a bit risky. You'd probably want a more sophisticated infrastructure which individually identifies players and allows for revocation, ala chip & pin.

Re: The Life of a Stripe Charge

#20

Post by patcheudor »

pbreit wrote: post #13
patcheudor wrote: post #7

Earlier quoted context omitted.

Then Stripe might want to reconsider their guidance in light of the PCI guidance on tokenization. Reference: "2.4.2 Merchant Responsibilities" https://www.pcisecuritystandards.org/documents/Tokenization_... The only way out of being responsible for PCI compliance would be to offload the entire transaction to the payment provider. This means sending the customer entirely off domain of the merchant (iFrames don't get y…

After reading the doc and paying close attention to that section, it's not clear to me what the Stripe problem is. I didn't see anywhere that the Stripe approach would not comply.

Because the merchant is still responsible for delivering the payment form within their same origin in a secure manner which means that the merchant must secure their hosts so that the delivery of that payment form cannot be tampered.
Post reply on HN