Live data from Hacker News

5900 online stores found skimming

gwillem.github.io

21–30 of 104 posts

Re: 5900 online stores found skimming

#22

Earlier quoted context omitted.

Most people don't want to bounce customers to a third party site for payment, it really hurts conversions. That is certainly true in my experience. Also, some of the payment services have a habit of changing the appearance and/or behaviour of their hosted systems, sometimes not for the better, and typically without warning. That is a risk you might not be willing to take for something as important as your payment flo…

I've worked with similar organizations that want the transaction on their site due to all the reasons mentioned in the comments. There are providers that use JavaScript to allow you to take payment information on your platform but never let the sensitive details hit your server. I believe this removes your platform as an attack vector for leaking credentials. The only locations that have traces of that information ar…

Unfortunately, even if your payment service is hosting the system that processes the sensitive details, there's always an element of vulnerability on the merchant's side if they are hosting the rest of the site, simply because a compromise could redirect customers to a hostile alternative site to collect those sensitive details. At that point, they're really no better off than a completely fake site that never had any real relationship with a payment service at all. Merchants should always be serving their own pages securely for this among other reasons, even if they are never intending to receive sensitive payment credentials.

Re: 5900 online stores found skimming

#23
post #18

Earlier quoted context omitted.

Does anyone know why the list has been censored ? Does it violate any law ?

Not that I know of. My guess is that somebody on that list threw a DMCA takedown notice at Github/Gitlab to get it pulled. Knee jerk reaction is to pull first, verify later.

That may have been the case with GitHub. Gitlab claimed that it fell into the same category as zero-day exploits (which is ridiculous), and that as such posting it wasn't responsible disclosure and it thus violated their ToS.

Re: 5900 online stores found skimming

#24
post #8

I constantly see various posts regarding credit card skimming and find it curious why 2 factor authentication is not enforced for all transactions. It's a simple solution, having someone's credit card info is not sufficient to make a transaction. Note: I am not from the USA. The 2FA solution is the default in my country, and I have literally never heard anyone lose money because of skimming.

The entire card payment system is fundamentally undermined from a security point of view, simply because it relies on merchants pulling funds instead of customers pushing them.

We would probably be much better off if we'd evolved a system where the payment authorisation step was always hosted by the customer's bank, and everyone expected that instead of putting card details or the like into some merchant's site, they would only ever deal with their own bank.

In the absence of such a system, modern 2FA schemes are trying to plug the gap, but they almost always introduce more friction in the process and consequently affect conversion rates. When not everyone is using them, that makes adopting 2FA potentially a worse option commercially than accepting the losses due to a certain level of fraud in return for better conversion rates across the board.

Re: 5900 online stores found skimming

#25

Earlier quoted context omitted.

You know it. I know it. Most of HN knows it. We are, in general, not the customer. On sites I've been involved with, in 2016, I still have to fight tooth and nail to get SSL on the payment page at all, let alone redirect users somewhere else.

On sites I've been involved with, in 2016, I still have to fight tooth and nail to get SSL on the payment page at all I'm reasonably sure that every payment service I've ever used requires payment pages to be served over HTTPS, not just HTTP, even those that have minimal other requirements and take on most of the security burden themselves with some sort of hosted arrangement. Are there really significant numbers of…

As a low tech experiment, I just grabbed the list that started this thread and tried a few random sites.

I only made it to the third one before I found an http:// checkout page. I tried to change the address to https:// and found it complaining about a cert mismatch. I also viewed source and confirmed the form submits to an http:// address.

So.... yes.

Re: 5900 online stores found skimming

#26
post #3

As the article points out, if someone can inject Javascript into your checkout page, you're most likely also having other security issues. Still, and I'm pretty much being called an idiot every time I point this out: You should NEVER have the user enter credit card information on your site. That is something that is best left to your PSP. If you're Amazon or similar size, fine, I can accept that you most likely have…

> leave it to Stripe, BrainTree, Paypal, someone trusted, with the resources to handle it.

Wouldn't stripe and braintree still effectively let you handle CC on your own site? i.e. If someone can inject JS code there, they can in high likelihood grab CC details even if you're using stripe or braintree. Am I missing something?

Re: 5900 online stores found skimming

#27
post #11
post #9

Earlier quoted context omitted.

There's a lot of hate against 3DSecure around here because a lot of banks and stores (seems primarily in the US and U.K.) have extremely poor implementations of it. Horror stories on here range from having the 3DSecure in an iframe to having horrible "secret question" style inline enrollment My banks implement it decently - weird third party URLs (albeit with the banks name on the EV certs), but using mobile 2FA apps…

3DSecure and the Visa equivalent (don't remember the name) are not really what I meant by 2FA. To make a transaction: -add items to cart -enter card details -you are redirected to 3DSecure if it's enabled -you are redirected to a page of your bank where you enter a One time Password(OTP). It's a simple 6 digit number sent to your mobile phone and is unique for every transaction.Enter OTP. -transaction is confirmed. S…

Two of my banks do it a little differently. With Visa's process (Verified by Visa), I had to register a password for each card. A separate password from my internet banking password. When I try to use my card on a VbV site (maybe one in ten sites), I have to enter three random characters.

So few sites require it that I don't remember the password and entering random characters from KeepassX is always a pain.

I hate it when I see that VbV prompt. That's frustrating security and results in passwords that you use so infrequently they never get changed. I'd much prefer OATH TOTP or even an SMS based code (with a "I don't have my phone" option).

Re: 5900 online stores found skimming

#28

Earlier quoted context omitted.

I've worked with similar organizations that want the transaction on their site due to all the reasons mentioned in the comments. There are providers that use JavaScript to allow you to take payment information on your platform but never let the sensitive details hit your server. I believe this removes your platform as an attack vector for leaking credentials. The only locations that have traces of that information ar…

Unfortunately, even if your payment service is hosting the system that processes the sensitive details, there's always an element of vulnerability on the merchant's side if they are hosting the rest of the site, simply because a compromise could redirect customers to a hostile alternative site to collect those sensitive details. At that point, they're really no better off than a completely fake site that never had an…

You are absolutely right.

Re: 5900 online stores found skimming

#29
post #3

As the article points out, if someone can inject Javascript into your checkout page, you're most likely also having other security issues. Still, and I'm pretty much being called an idiot every time I point this out: You should NEVER have the user enter credit card information on your site. That is something that is best left to your PSP. If you're Amazon or similar size, fine, I can accept that you most likely have…

I work in ecommerce consulting - most of my clients take CC info on their site, the forms on the checkout POST (over SSL) to the PSP who then return a token to the site, all future transactions use the token. Most people don't want to bounce customers to a third party site for payment, it really hurts conversions.

I don't understand this at all. I really, really don't want to give my credit card details to some random webshop who are exceedingly unlikely to have solid security. If I can use PayPal or another well known payment provider, great, I don't even have to type in my details. But even a less well known PSP is more likely to get it right than a small business webshop.

A slightly jarring user interface seems a small price to pay for a much lower chance of my payment details being compromised. Is this a minority view?

Post reply on HN