Those stores need to be reported to some entity. Maby VISA?
The FBI.
In any case the only operate in USA.
21–30 of 104 posts
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…
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.
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.
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.
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…
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.
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…
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?
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…
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).
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…
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.
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?