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

111–120 of 125 posts

Re: Accepting payments is getting harder

#111

Post by matthewarkin »

jtdowney wrote: post #106
matthewarkin wrote: post #60

Earlier quoted context omitted.

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

At Braintree, we have been working on the approach you mentioned. We’ll soon update our iframe products to allow a merchant to opt-in to only ever receiving cardholder data via the Braintree iframe. With this change, we could actively block malicious JavaScript from rewriting the merchant form by rejecting data not from the Braintree iframe. Things like this aren't a panacea though which is why it’s important for mer…

I think more awesome, was the hosted fields you just launched, so that I can have a custom, stylized form where each credit card input is its own iframe.

https://www.braintreepayments.com/features/hosted-fields

Re: Accepting payments is getting harder

#112

Post by jtdowney »

matthewarkin wrote: post #111
jtdowney wrote: post #106

Earlier quoted context omitted.

At Braintree, we have been working on the approach you mentioned. We’ll soon update our iframe products to allow a merchant to opt-in to only ever receiving cardholder data via the Braintree iframe. With this change, we could actively block malicious JavaScript from rewriting the merchant form by rejecting data not from the Braintree iframe. Things like this aren't a panacea though which is why it’s important for mer…

I think more awesome, was the hosted fields you just launched, so that I can have a custom, stylized form where each credit card input is its own iframe. https://www.braintreepayments.com/features/hosted-fields

I agree! I submitted it as separate item because this conversation was about rewriting iframes. Although hosted fields doesn't directly address the rewriting for now, we're looking at it closely.

Re: Accepting payments is getting harder

#113

Post by twothamendment »

fragmede wrote: post #58
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.

Discover card has gone back and forth on this. They had a tool on their site to give you a throwaway CC #. I used it for almost all online purchases. It went away for a short time, then came back. Now it looks like it is gone for good. I quit using their card since that was the only reason I had to use it over others.

Now if they'd only stop sending me "checks" in the mail that are tied to my account... I'm just waiting for those to be spent by someone else.

Re: Accepting payments is getting harder

#114

Post by mcdougle »

jamiesonbecker wrote: post #103
benmanns wrote: post #98

Earlier quoted context omitted.

For 2), it looks like Balanced payments accepts ACH debits. https://www.balancedpayments.com/ach-debits

Apparently not any more. Balanced shutting down (RIP) https://www.balancedpayments.com/stripe/faq

I emailed them with a question and that's the response I got. Too bad, there seems to be a need out there for an automated bank account payment API.

Re: Accepting payments is getting harder

#115

Post by [deleted] »

BlackFly wrote: post #53
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…

[deleted]

Re: Accepting payments is getting harder

#116

Post by nsxwolf »

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…

Can you elaborate on what manual tests are and why they are better? Coming from a software QA perspective, automated tests provide repeatability and prevent omissions and aid with regression testing.

What are "manual tests" in the infosec context?

Re: Accepting payments is getting harder

#117

Post by borski »

jerematasno wrote: post #99
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…

> Penetration tests, when done by a good firm like Matasano, are incredibly useful, but lose their value the next time you push code. I'd like to nicely but firmly push back on this one, and have longitudinal analysis of clients' applications to back it up. We put a lot of effort into helping our customers improve over time, both formally (writing helpful recommendations) and informally (educating developers during a…

Ah, you misunderstood what I meant. I didn't mean to imply that penetration tests, when done well, have no lasting value. I simply meant to imply that without a code freeze, there is always the chance of a new vulnerability creeping in no matter how well you follow checklists, best practices, or retain knowledge about types of vulnerabilities and how not to build them.

For that reason, automated testing on a continuous basis is important.

This is the same reason that you don't QA an application once a year. UIs change, requirements change, and for that you write integration tests, unit tests, etc.

Does that clarify things a bit? I didn't mean to imply Matasano did a poor job of educating their customers; in fact, I think you're among the best.

Re: Accepting payments is getting harder

#118

Post by borski »

akshatpradhan wrote: post #93
borski wrote: post #81

Earlier quoted context omitted.

Ha, good to see you here. I'm not suggesting that there is absolutely no value to any of PCI. The fact that it forces you to think about security at all is already of some value. However, I am saying that passing a PCI audit is incredibly easy as compared to thorough automated testing, and especially compared to a (good) manual penetration test. Because you can pass a PCI audit relatively easily, people will do that…

>If you have to pick exactly /one/ thing to do in addition to (or instead of) PCI, building thorough automated security testing into your SDLC process is it. I don't understand how SDLC secure testing is an addition to PCI when its really a sub requirement of PCI (Req 6 which addresses SDLC and secure code testing) I'm going to rephrase because I'm still confused: You're saying that in addition to doing PCI, I should…

Show me where it suggests automated testing as a regular part of your SDLC. It recommends applying patches, coding to secure guidelines / best practices, doing code reviews, and running an automated or manual pen test at least once a year. Nowhere does it state in Requirement 6 that you should build automated testing into your SDLC.

Reference: https://www.pcisecuritystandards.org/documents/pci_dss_v2.pd...

Re: Accepting payments is getting harder

#119

Post by [deleted] »

borski wrote: post #118
akshatpradhan wrote: post #93

Earlier quoted context omitted.

>If you have to pick exactly /one/ thing to do in addition to (or instead of) PCI, building thorough automated security testing into your SDLC process is it. I don't understand how SDLC secure testing is an addition to PCI when its really a sub requirement of PCI (Req 6 which addresses SDLC and secure code testing) I'm going to rephrase because I'm still confused: You're saying that in addition to doing PCI, I should…

Show me where it suggests automated testing as a regular part of your SDLC. It recommends applying patches, coding to secure guidelines / best practices, doing code reviews, and running an automated or manual pen test at least once a year. Nowhere does it state in Requirement 6 that you should build automated testing into your SDLC. Reference: https://www.pcisecuritystandards.org/documents/pci_dss_v2.pd...

[deleted]

Re: Accepting payments is getting harder

#120

Post by akshatpradhan »

borski wrote: post #118
akshatpradhan wrote: post #93

Earlier quoted context omitted.

>If you have to pick exactly /one/ thing to do in addition to (or instead of) PCI, building thorough automated security testing into your SDLC process is it. I don't understand how SDLC secure testing is an addition to PCI when its really a sub requirement of PCI (Req 6 which addresses SDLC and secure code testing) I'm going to rephrase because I'm still confused: You're saying that in addition to doing PCI, I should…

Show me where it suggests automated testing as a regular part of your SDLC. It recommends applying patches, coding to secure guidelines / best practices, doing code reviews, and running an automated or manual pen test at least once a year. Nowhere does it state in Requirement 6 that you should build automated testing into your SDLC. Reference: https://www.pcisecuritystandards.org/documents/pci_dss_v2.pd...

Just so we're clear, what do you define as automated testing? Let me know.
Post reply on HN