Accepting payments is getting harder • Hacker News Board

Re: Accepting payments is getting harder

#51

Post by hueving » Fri, May 08, 2015, 8:32 AM UTC

dsacco wrote: post #25

sjtgraham wrote: post #6

> The worst offenders however are the requirements that some businesses simply cannot comply with unless they have some serious cash laying around. Examples of this are >> Quarterly external vulnerability scans must be performed by an Approved Scanning Vendor (ASV), approved by the Payment Card Industry Security Standards Council (PCI SSC). > and >> Is external penetration testing performed per the defined methodolog…

I'm sorry that's been your experience. What should have happened is a primarily manual penetration test, administered by security engineers who themselves used to be fully competent software developers. Any automated tooling should have had strict manual verification and should not have been the focus of the test. Furthermore, superfluous results should not have been submitted in the PDF report. Strictly "policy" aud…

>These are not real infosec firms, they are parasites.

The entire consulting penetration testing market is setup to encourage this behavior. There is no way to prove you actually did anything correct. Someone can write a wonderful PDF analysis by hand and still leave the system full of glaring holes. Customers can't tell a system is broken until it gets hacked.

>More specifically, we ask for it and we receive it, and we do exceedingly well. If people keep paying us five figures a week to perform a penetration test, we're not going to stop asking for it or reduce our prices.

Right, but many times I've seen companies do it because they are desperate to do it for compliance purposes. :/ Essentially there is a non-trivial portion of the market held up by regulatory demand.

>Strictly "policy" audits such as PCI compliance differ a bit, but in general they should still involve a technical deep dive into your product's infrastructure, conducted by consultants with expertise in multiple tech stacks and overall experience in a variety of frontend and backend frameworks.

I'm curious. Do you review every line of code in a customer's codebase? What about the code of every library they import? If you don't review imports, do you leave a big caveat in your report that says their code looks okay, but the libraries could be full of vulnerabilities?

Re: Accepting payments is getting harder

#52

Post by cm2187 » Fri, May 08, 2015, 8:49 AM UTC

We should have moved a long time ago to vendor specific credit card numbers (ecommerce isn't exactly a new activity). Say I get from my bank a token which I provide to this vendor, and the first time the vendor uses it to accept a payment, the token locks in to that vendor, i.e. my bank will not allow any payment with this token to another vendor (i.e. to another bank account). Then it doesn't matter if it's stolen, only that vendor can use it anyway. And I could have the option to tell my bank to make it a single use token, or to cancel a multiple use token or to set a payment cap to that token.

That doesn't seem very complex to implement and would alleviate the vast majority of the credit card related problems. I am sure it can be made simpler, have a protocol with redirects to the bank's website that eliminate the need for the client to copy-paste a token, or to have another mechanism with similar effects.

Banks are one of these many industries that don't seem to get technology. They employ massive IT and developer staff but are run by people who don't get it (and to make things worse, are most of the time massive bureaucracies which means that even when they know what they need to do they just can't execute).

Re: Accepting payments is getting harder

#53

Post by BlackFly » Fri, May 08, 2015, 8:51 AM UTC

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…

The real solution to the problem is use of an integrated circuit card, usually through EMV.

If a web merchant uses 3D secure or Verified By Visa or SafeKey (from MC, Visa and AmEx respectively), the issuing bank can implement the same level of security in a web transaction that occurs in a card present chip transaction. Proof that the transaction was originated by someone who has control over the card, proof that the transaction was originated by someone who has knowledge of the PIN.

In these schemes you can store the PAN all you want. As long as the 3DES key is never read from the card, the PAN does you no good. Hopefully, when the USA catches up to the rest of the world in this regard, PCI will relax security requirements for merchants/acquirers.

Re: Accepting payments is getting harder

#54

Post by raesene4 » Fri, May 08, 2015, 8:52 AM UTC

hueving wrote: post #51

dsacco wrote: post #25

Earlier quoted context omitted.

I'm sorry that's been your experience. What should have happened is a primarily manual penetration test, administered by security engineers who themselves used to be fully competent software developers. Any automated tooling should have had strict manual verification and should not have been the focus of the test. Furthermore, superfluous results should not have been submitted in the PDF report. Strictly "policy" aud…

>These are not real infosec firms, they are parasites. The entire consulting penetration testing market is setup to encourage this behavior. There is no way to prove you actually did anything correct. Someone can write a wonderful PDF analysis by hand and still leave the system full of glaring holes. Customers can't tell a system is broken until it gets hacked. >More specifically, we ask for it and we receive it, and…

Whilst I'm not the parent commenter I do work in the same industry..

>>These are not real infosec firms, they are parasites.

>The entire consulting penetration testing market is setup to encourage this behavior. There is no way to prove you actually did anything correct. Someone can write a wonderful PDF analysis by hand and still leave the system full of glaring holes. Customers can't tell a system is broken until it gets hacked.

So a good company should be able to provide a methodology detailing the tests they do, you'll also see some who report the tests conducts and the results (positive or negative), so asking for sample reports from consultancies would help to find one closer to your specific needs. Personally I prefer reporting all test results as it keeps both parties straight on what has and has not been covered.

>>More specifically, we ask for it and we receive it, and we do exceedingly well. If people keep paying us five figures a week to perform a penetration test, we're not going to stop asking for it or reduce our prices.

>Right, but many times I've seen companies do it because they are desperate to do it for compliance purposes. :/ Essentially there is a non-trivial portion of the market held up by regulatory demand.

Yeah where people are getting tests for purely compliance reasons there is a tendency to go with cheap suppliers as there's not really good perceived benefit.

>>Strictly "policy" audits such as PCI compliance differ a bit, but in general they should still involve a technical deep dive into your product's infrastructure, conducted by consultants with expertise in multiple tech stacks and overall experience in a variety of frontend and backend frameworks.

>I'm curious. Do you review every line of code in a customer's codebase? What about the code of every library they import? If you don't review imports, do you leave a big caveat in your report that says their code looks okay, but the libraries could be full of vulnerabilities?

Heh this is one of the huge gaping holes in security at the moment. Most applications are now constructed of piles of code acquired from repos (npm, nuget, rubygems etc) that provide absolutely no curation of content and anyone can put any code they like up there. There is (from what I've seen) very little appetite from companies to actually try and audit their whole stack, generally due to the cost of doing that. Manual code review is expensive and when you start importing 100Kloc of 3rd party code into your solution it would not be a cheap excercise to validate...

Re: Accepting payments is getting harder

#55

Post by chinathrow » Fri, May 08, 2015, 8:56 AM UTC

matthewarkin wrote: post #42

aethr wrote: post #33

Earlier quoted context omitted.

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 ske…

So where's the news then? Malicious JS is known to be bad.

Would the next step be to turn of JS at all? Or go back to hosted cc forms only?

Re: Accepting payments is getting harder

#56

Post by nmridul » Fri, May 08, 2015, 9:04 AM UTC

cm2187 wrote: post #52

We should have moved a long time ago to vendor specific credit card numbers (ecommerce isn't exactly a new activity). Say I get from my bank a token which I provide to this vendor, and the first time the vendor uses it to accept a payment, the token locks in to that vendor, i.e. my bank will not allow any payment with this token to another vendor (i.e. to another bank account). Then it doesn't matter if it's stolen,…

This is similar to how bank payment is working in India. When I make payment on seller website, it redirects me to the bank website. I enter my credentials (including phone based or device based OTP) to confirm the payment and its done. And there is also option to make easy subscriptions.

Re: Accepting payments is getting harder

#57

Post by [deleted] » Fri, May 08, 2015, 9:04 AM UTC

matthewarkin wrote: post #42

aethr wrote: post #33

Earlier quoted context omitted.

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 ske…

[deleted]

Re: Accepting payments is getting harder

#58

Post by fragmede » Fri, May 08, 2015, 9:11 AM UTC

cm2187 wrote: post #52

We should have moved a long time ago to vendor specific credit card numbers (ecommerce isn't exactly a new activity). Say I get from my bank a token which I provide to this vendor, and the first time the vendor uses it to accept a payment, the token locks in to that vendor, i.e. my bank will not allow any payment with this token to another vendor (i.e. to another bank account). Then it doesn't matter if it's stolen,…

Bank of America has ShopSafe which allows you to generate a temporary credit card number to use with the sketchy online merchant that has the particular gadget I want to buy.

Their implementation leaves much to be desired, but it's a step in the right direction.

Re: Accepting payments is getting harder

#59

Post by fastball » Fri, May 08, 2015, 9:12 AM UTC

cm2187 wrote: post #52

We should have moved a long time ago to vendor specific credit card numbers (ecommerce isn't exactly a new activity). Say I get from my bank a token which I provide to this vendor, and the first time the vendor uses it to accept a payment, the token locks in to that vendor, i.e. my bank will not allow any payment with this token to another vendor (i.e. to another bank account). Then it doesn't matter if it's stolen,…

Maybe you should start a tech-savvy bank. Might gain a lot of traction.

Or we could all adopt bitcoin. :p

Re: Accepting payments is getting harder

#60

Post by matthewarkin » Fri, May 08, 2015, 9:17 AM UTC

chinathrow wrote: post #55

matthewarkin wrote: post #42

Earlier quoted context omitted.

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 ske…

So where's the news then? Malicious JS is known to be bad. Would the next step be to turn of JS at all? Or go back to hosted cc forms only?

Historically, the thought has been that the iframe and a redirect could both be treated as SAQ A (the easiest form of compliance), was because if you changed the iframe that was displayed or the page the customer was linked to it would be extremely difficult to steal customer information in a silent way.

So if a merchant links to paypal.com/merchant, and I inject js to change it to paypal.com/matthewarkin. The merchant would immediately know something was wrong because they are no longer receiving money. The issue with how Stripe, Braintree, and others have implemented their javascript and iframe implementations is that is pretty easy to replace the iframe with a malicious url (paypal.com/matthewarkin) but still allow the merchant to receive their funds.

A simple fix for this would be the api keys used to instantiate the iframe only be usable from the iframe and could not be used to call the create token api directly.