Prevent Card Testing - Stripe Proform

#21

Thanks for the helpful configuration tips. Much appreciated :slight_smile:

Regarding your hacker going away…keep an eye on it. I have experienced the bizarre hacker behavior which is they take weekends and holidays off. I know…weird. You don’t think of hackers as clocking in and clocking out like the rest of us but I guess if you’re part of a hacker mill it’s just a day job like any other. I had a war of attrition with a forum link-stuffer for about 3 months before they finally gave up and moved on to a forum that was less of a hassle for them.

#22

Actually after another try for an attack 3 years later I now went for approval 50-80, and block 50.
Stripe radar and the nginx rate limiting will do.

And another thing, they tend to use disposable email addresses, so just confirming email works is not helping much. Of course they would not know in that case that there is a credit card form hidden. It worked well enough without a captcha however. As long as your website is harder to attack than others that’s enough. So strict Stripe radar and rate limiting the checkout page is good enough to deter card testers.

PayPal seems to have something similar to stripe radar too now, I don’t know because I use button payments only and then the problem is shifted to PayPal as they checkout on Paypal website. It’s rather that PayPal is unnecessary strict and blocks much more than I do with the rules above for people trying to pay without PayPal account.

With strict radar rules the card testers will actually have legitimate numbers shown as not working so it undermines their efforts. Because they will never know why their payment didn’t go through. Was it the CVC or the address or the zip code or their IP or their email.

Btw i don’t block disposable email because I quite often have legitimate users using them for data security. It’s a bit of a pain afterwards for me but quite likely blocking disposable email would lose me half of them in first place. As a small website this is hard to prevent.

1 Like
#23

Thanks for the update, Felix.

Are those attacks/attempts automated, or do you think by hand?

I found that something that was simple and successful to help me prevent spam bot registrations, was adding an s2 custom profile field with a required format (e.g. something simple like a minimum of 5 characters).

If the attempts are done by a similar script to the spam registration ones, maybe that’d help, too.

#24

I guess first one by hand to start/create a script then a bot takes over if successfull. If you have no protection whatsoever as I had in first place 3 years ago (I did have a quite lax stripe radar at least) and the network puts down 100,000 request per day that’s quite serious. It makes sense to first put a human check out the target.

1 Like
#25

I guess the best would be if s2member could lock down the payment form if more than XX bad credit card payments within an hour. Or at least lockdown for non registered users.

Though with password leaks I had a couple of users taken over. Still I don’t like to block leaked passwords because it causes too much support trouble. Usually they take over and just post spam comments only anyhow.

2 Likes