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

Accepting payments is getting harder

medium.com

Post reply on HN
Print view View original

41–50 of 125 posts

Re: Accepting payments is getting harder

#41

Post by lazaroclapp »

ique wrote: post #19
Animats wrote: post #18

This is good. People are getting fed up with replacing their credit card every six months because some online retailer had a breach. You can outsource payment processing to Stripe, Paypal, Square, Yahoo Store, etc. There's no reason every web merchant should see credit card numbers. Stripe is in Visa's doghouse right now.[1] Their entry on the Visa Global Registry of Service Providers has turned yellow, with an expir…

> There's no reason every web merchant should see credit card numbers. The heightened requirements are actually for when you are using services that _don't_ let the merchant see the CC number. Like the "old" Stripe.js.

So long as stripe.js is linked from your site, there is nothing preventing someone who can breach your server from seeing all CC numbers going through that page (namely by modifying the served stripe.js). It is just as insecure as processing the CC numbers on the server yourself, but deleting them after confirming the transaction.

I know for a fact that Stripe is staffed by some really brilliant people, so maybe I am missing something, but as far as I understood, their business model has always been: "ease the legal requirements on merchants by making use of the technicality of not sending CC info to their servers, while still not significantly adding security to CC processing".

But this is kinda a fundamental issue with the whole CC# system, one that redirecting to "trusted processors" just marginally improves. It stretches belief sometimes that in 2015 we have full-disk encryption and TLS-everywhere, but not a sane financial transaction system based on public-key signatures (hopefully we are moving in that direction now? and getting chips in US cards?).

Re: Accepting payments is getting harder

#42

Post by matthewarkin »

aethr wrote: post #33
matthewarkin wrote: post #24

Earlier quoted context omitted.

I'm actually working on a blog post about this, basically the argument is whether or not you use Stripe.js and the invisible iframe and Stripe Checkout is that as soon as you have some malicious JS in your DOM all bets are off, and while stealing credit card info from Stripe Checkout may be harder than just doing $("#credit-card-number").value, its not /that/ much harder. (As part of my blog post, I actually use some…

Very interested to see your blog post. I was under the impression that if the data is collected in an iframe with a same-origin policy, that malicious JS in the containing page wouldn't have access to form elements (or anything) inside the iframe. Of course if you have malicious JS in your DOM, there's nothing stopping it from rendering it's own legit-looking credit card form that simply passes data off to an externa…

Thats basically the concept, once you have malicious js you can replace the iframe with a malicious one that looks the same. You can even have it still create a legitimate card token, so in theory the website would never know they are hacked. The other PCI SAQ A scenario is linking off site. So while malicious JS could change the link you redirect to customers to it would be noticed because the customer may see a sketchy url and the merchant would see a decrease in sales.

Re: Accepting payments is getting harder

#43

Post by [deleted] »

aethr wrote: post #33
matthewarkin wrote: post #24

Earlier quoted context omitted.

I'm actually working on a blog post about this, basically the argument is whether or not you use Stripe.js and the invisible iframe and Stripe Checkout is that as soon as you have some malicious JS in your DOM all bets are off, and while stealing credit card info from Stripe Checkout may be harder than just doing $("#credit-card-number").value, its not /that/ much harder. (As part of my blog post, I actually use some…

Very interested to see your blog post. I was under the impression that if the data is collected in an iframe with a same-origin policy, that malicious JS in the containing page wouldn't have access to form elements (or anything) inside the iframe. Of course if you have malicious JS in your DOM, there's nothing stopping it from rendering it's own legit-looking credit card form that simply passes data off to an externa…

[deleted]

Re: Accepting payments is getting harder

#44

Post by matthewarkin »

Animats wrote: post #18

This is good. People are getting fed up with replacing their credit card every six months because some online retailer had a breach. You can outsource payment processing to Stripe, Paypal, Square, Yahoo Store, etc. There's no reason every web merchant should see credit card numbers. Stripe is in Visa's doghouse right now.[1] Their entry on the Visa Global Registry of Service Providers has turned yellow, with an expir…

Stripe got their QSA to renew them but Visa hasn't updated their site was what I was told.

Their Attestation of Compliance: https://www.dropbox.com/s/xpk1n72n0gtd5o5/Stripe_AOC_2015.pd...

Re: Accepting payments is getting harder

#45

Post by Silhouette »

As a small business taking card payments, we're far more concerned about the absurd rate of failure of perfectly legitimate charges than anything PCI-DSS say. We lose more customers to Stripe charges failing than any other reason, by a considerable margin, and it seems even Stripe don't actually know why because it's organisations further down the line making these decisions.

The whole card payments industry is broken, and the sooner the growing direct payments industry kills off the credit card giants, the better.

Re: Accepting payments is getting harder

#46

Post by akshatpradhan »

borski wrote: post #38

For what it's worth, PCI compliance as it stands today is complete BS. It provides a false sense of security and most of the PCI ASVs are the scourge of infosec. I can't tell you how many customers we have that use the cheapest possible PCI ASV for "compliance," but then use us in addition for "real security," despite the fact that we aren't an ASV. We've intentionally stayed away from becoming one thus far, actually…

TinFoil, I remember I invited you to speak at the Boston Security Meetup several years ago!

>The real solution, as I see it, is to build automated security testing into your SDLC / Dev process. Penetration tests, when done by a good firm like Matasano, are incredibly useful, but lose their value the next time you push code. Building tools like Tinfoil into your CI process makes sure you don't get owned between pen tests.

This is false because you're suggesting that security testing of your SDLC, a subset of the compliance program is a more diligent solution than the entire compliance program. I explain myself in a comment below and I'd be glad to debate with you: https://news.ycombinator.com/item?id=9510369

Re: Accepting payments is getting harder

#47

Post by matthewarkin »

ique wrote: post #34
eps wrote: post #30

Earlier quoted context omitted.

Do elaborate ... And what is old/new stripe.js ?

With the old Stripe.js, you serve up the form but the Stripe javascript takes over the form and posts directly to Stripe, so your servers never see the data. The new Stripe.js will render an iFrame, (Edit:) through which Stripe will send the data, which again posts to directly to stripe. They basically behave the same way and will look the same way, the only difference is that the iFrame is in it's own Javascript "do…

The new Stripe.js does not render an iframe, the credit card information is still entered on your site so $("#credit-card-number").val() would return the card number. The transmission of the card data happens through the iframe. So the card number gets copied to the iframe, and the iframe makes the post to Stripe.

Re: Accepting payments is getting harder

#48

Post by Silhouette »

lazaroclapp wrote: post #41
ique wrote: post #19

Earlier quoted context omitted.

> There's no reason every web merchant should see credit card numbers. The heightened requirements are actually for when you are using services that _don't_ let the merchant see the CC number. Like the "old" Stripe.js.

So long as stripe.js is linked from your site, there is nothing preventing someone who can breach your server from seeing all CC numbers going through that page (namely by modifying the served stripe.js). It is just as insecure as processing the CC numbers on the server yourself, but deleting them after confirming the transaction. I know for a fact that Stripe is staffed by some really brilliant people, so maybe I am…

So long as stripe.js is linked from your site, there is nothing preventing someone who can breach your server from seeing all CC numbers going through that page (namely by modifying the served stripe.js). It is just as insecure as processing the CC numbers on the server yourself, but deleting them after confirming the transaction.

This has always been a weak argument though, because if someone can breach your server, they can impersonate whatever they like from a typical visitor's point of view and see whatever data anyone enters. They can do this even if you're not a legitimate merchant at all and don't even use a credit card payment service.

Card payment security is fundamentally broken.

Re: Accepting payments is getting harder

#49

Post by lazaroclapp »

Silhouette wrote: post #48
lazaroclapp wrote: post #41

Earlier quoted context omitted.

So long as stripe.js is linked from your site, there is nothing preventing someone who can breach your server from seeing all CC numbers going through that page (namely by modifying the served stripe.js). It is just as insecure as processing the CC numbers on the server yourself, but deleting them after confirming the transaction. I know for a fact that Stripe is staffed by some really brilliant people, so maybe I am…

So long as stripe.js is linked from your site, there is nothing preventing someone who can breach your server from seeing all CC numbers going through that page (namely by modifying the served stripe.js). It is just as insecure as processing the CC numbers on the server yourself, but deleting them after confirming the transaction. This has always been a weak argument though, because if someone can breach your server,…

Redirecting to a external processor still works to some degree, assuming people check for say "[PayPal, Inc [US]]" in their address bar. I am not arguing that the iframe thing is really better (specially not an invisible iframe). I am arguing that there are good reasons for requirements to be more demanding than "you must send your POST requests to a trusted server".

I suppose ideally we should have platform support for this sort of thing, though. Perhaps something like a payments browser API, hopefully supporting multiple processors (like most browser's search bars). After set-up it should be as simple as getting a browser-level pop-up asking you to confirm the amount or cancel it (plus any sort of auth required by the processor, which hopefully should be as simple as nothing for small transactions and tapping your card to the NFC reader for large ones).

Re: Accepting payments is getting harder

#50

Post by mrweasel »

It's only getting harder if you have "inline" payment. Honestly I'm glad to see that go away.

We always used "hosted payment page" solution, it's safer, and we've been expecting tougher rules for some time.

If you want to talk about online payment becoming harder, you should address the increasing number of payment options that online stores need to support. Adding to debit and credit cards are bank transfers (which is different in every country), PayPal, invoicing, part-payments, financing, and an almost unlimited number of local option.

Post reply on HN