Hacker News Reader

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.

This solution is already implemented in large parts of the world and good to go! But the incentives are sometimes not right. Ultimately, I want IC payments to be cheaper, as a merchant. I want my incoming IC payments to be in a separate bookkeeping from the non-IC: increase in fees on the latter, I'd like to keep my rates for the former.

Ultimately, I can then pass these savings on to the customers.

But as long as there is no incentive to ask for IC, why would I? It's just an annoyance.

I'm a bit confused as to what you mean.

Physical merchants eliminate liability for fraud and get reduced interchange fees by accepting chip.

Web merchants get reduced fees by using 3D secure (and the other scheme's versions). It is the issuing banks decision whether the 3D secure uses a chip or not, not the decision of the merchant. Many banks use sms push, RSA tokens, OTP sent in an envelope, or just passwords.

My understanding is that

- The liability shift will pressure merchants just to use EMV-capable terminals. As long as they're using one they won't be penalized for swiping.

- However, the networks require certified EMV terminals to reject swipes from chip cards. (They can tell from the service code in the card's track data.) Unless dipping fails a certain number of times, in which case the terminal can allow swiping as a fallback.

So merchants are incentivized to get an EMV-capable terminal, issuers are incentivized to replace magstripe cards with ICCs, and terminal requirements (mostly) prevent swiping ICCs.

There is a major use case around "card not present" transactions.

Anything recurring, such as AWS, hotel/car rental express check-out/return, Amazon 1-click and Uber and similar mobile payment use cases will get significantly higher friction if you have to complete a chip-and-pin for each of these.

A quite simple fix to these would be to allow storage of a token linked to the PAN which is locked to a specific merchant - so, they're worthless if stolen, but can be used like the PAN is today to perform "card not present" transactions for that merchant.

This problem has already been solved.

Most interchange protocols contain flags for recurring payments and standing authorizations. Only the first such transaction contains chip data to prove that the cardholder actually wants to authorize a standing auth/recurring auth.

In these cases, the standing authorization is already tied to the merchant + PAN + address details. Using chip in the first place is what allows a database compromise which leaks the PAN to not enable a criminal to authorize at another merchant: they won't be able to generate the ARQC needed to authorize.

All subsequent standing auths are card not present anyways.

What has 3D Secure got to do with EMV? How is it supposed to use the chip and the PIN?

Verified by Visa is bad for the consumer: it shifts all the risk of fraud onto them. If the PIN is intercepted, and subsequent purchases are made with that PIN, the owner of the card is liable for all of those purchases; they are considered to have made them because their pin was present at the time of purchase.

That's generally been the case in Europe, but as I understand it this "liability shift" would be more difficult to enact in the U.S., because U.S. law has blanket limits on consumer liability for credit-card fraud (maximum $50 for card-present transactions and $0 for card-not-present). There are exceptions if the bank can show that you were negligent, e.g. you knew a card was stolen but failed to report it in a timely manner, but the burden of proof remains on the bank in those cases.

>If a web merchant uses 3D secure or Verified By Visa or SafeKey (from MC, Visa and AmEx respectively)

then he better hope that all his competitors do to. It is a major hassle and risk for the consumer so I haven't set my card up to work with those. If it gets stolen it gets stolen but that can happen even if I get it verified.

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...

Actually Visa's Global Registry is in the doghouse right now. They have a very slow, antiquated process to get listed (only update it once a month, must be ready to go two week prior to that update, you go into a blackhole and never know if you'll actually get swept up in the latest update) which used to be ok but this year they began with a more aggressive approach of marking you orange and delisting you. It's impacting a lot of folks right now and I wouldn't read anything into this and Stripe's status.

> 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.

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

> they are changing Stripe.js to now serve up the data in an iFrame so you can keep using their product more or less like before but without heightened requirements

I imagine they're changing things to be like Google Wallet, where you use a pop-out window to type your credit card number into (just the first time, it's save on their side after). That way you know you're giving your CC just to google.com by looking at the URL of the new window.

Stripe's current JS-based version has better UX, but it's a little scary if the merchant whose site you're entering your card into has no legal security requirements. On the other hand, it's a purely theoretical problem afaik - I haven't heard of any breaches resulting from merchants which use JS third party payment solutions having their websites hacked to serve up bad JS.

I've seen non-https sites serve up HTTPS iframes. The whole iframe thing just seems like a bad idea for processing credit information. Ignoring HTTP interception, it's difficult for customers to verify that the iframe is indeed coming from an HTTPS site.

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 "domain" so that if your site is infected with malicious javascript it can't take over the POST to stripe as easily (although that is debatable).

The former requires really high security requirements now and the latter requires almost none.

> the iFrame is in it's own Javascript "domain" so that if your site is infected with malicious javascript it can't take over the POST to stripe as easily (although that is debatable).

A malicious attacker could simply replace the entire iframe with something else that looks identical, but sends a copy of the CC details to some other server.

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.

You are right, editing my comment.

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?).

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.

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).

Braintree too, Feb28, 2015

edit: actually I'm seeing Google there Jan 31, 2015 , so I wouldn't pay too much attention to this. Likely they fix up before anyways.

Visa's put Google on red status. Wow. Wonder what Google's problem is.

Visa's list is what Google's problem is.

I used Google Checkout as a merchant once years ago and it was a horrible experience. Customer service was appalling. They ultimately ended up revoking our account and keeping the balance (it was low enough to not be worth fighting them over).

Visa is slow at updating their site. MasterCard is much faster, you can find their list at http://www.mastercard.com/us/company/en/docs/SP_Post_List.pd....

There is of course alternative technical solutions to this problem, one being virtual credit card that can be used once per purchase. I would not trust that the outsourced payment processing system never get a breach.