Skip to content

Comment on Flock Safety's controversial CEO just got a taste of his own medicineparent

Comments

My employer is a small business that has an e-commerce website that is attacked by fraudsters trying to validate stolen credit cards or obtain customer information hundreds of times per day. Operations like CloudFlare are the only way to foil these actors. Just trusting you is not a viable strategy.

I had this problem too for all my clients e-commerce websites, then solved it 3 years ago with very little code changes.

Happy to share it with you. Using small businesses for credit card testing is one of the most evil things on the Internet, so anything to stop it is worth it.

The people who downvote could propose how to solve the fraudster problem instead of shooting the messenger.

"We removed the wheelchair ramp because it was used by rodents to enter our building."

"Don't shoot the messenger!"

Security can't be a reason for discrimination.

So keep the ramp then. Now your business is full of rats and even the disabled don't want to shop there. What do you do now?

Edit: The downvotes have spoken! This view is simply wrong with no justification!

That isn't the done thing here, lamentably. Downvote is a de facto disagree button

Your rate limits on adding and removing credit cards? Your input sanitization? Designing your system to not just disclose details around anything but that relevant to a logged in/authenticated user?

There are many practical ways to handle that sort of thing that isn't Cloudflare. It just requires thinking and a bit of dev time.

t. Been there, done that, cartels used an app to try to launder money through loyalty programs. Management was deadset against doing the one single thing that would make it impossible to do that at scale.

Ulterior motives abound everywhere but especially behind people claiming X is the only answer. Fingerprinting is far more intrusive than just only allowing one to add at max 2 cards a day per user.

Your rate limits on adding and removing credit cards?

All those requests will appear from different ip's and different browsers, made by someone who can spend months on trying to defraud you. How do you differentiate this from valid customer who happens to try to buy something between 20 tries by bots?

Your input sanitization?

All those fraud requests will give you valid credit cards which will work perfectly, but then defrauded people or banks will try to chargeback later.

Designing your system to not just disclose details around anything but that relevant to a logged in/authenticated user?

They can register as normal buyers.

It just requires thinking and a bit of dev time.

And they can spend months trying to outthink you, then will drain your service in 4 hours when you are asleep.

Management was deadset against doing the one single thing that would make it impossible to do that at scale.

So, did you actually ever implemented and checked a good solution? Cloudflare isn't perfect, but not everyone has resources to implement their own solution that is better than cloudflare.

Fingerprinting is far more intrusive than just only allowing one to add at max 2 cards a day per user.

The fraudsters will appear as completely new users each time, adding only one card and making one purchase.

All those fraud requests will give you valid credit cards which will work perfectly, but then defrauded people or banks will try to chargeback later.

How are they getting pass 3D-S?

If they are able to get past it, then your liability drops off.

Yes it could be designed better, but that is a separate discussion.

It doesn’t matter that they can’t get past 3D-S, because the whole point of what they’re doing is checking what security features are enabled for a card, and whether their address and other validation data will pass. The fact that the scammers are testing so many cards that fail gets you banned from those payments providers, whether or not any payments go through. And this is ignoring all the attackers using bots for other purposes such as taking control of the website to obtain user or client data.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.