Not stopping bots from making user accounts

Since you are using Cloudlfare, you might consider making a Cloudflare custom WAF rule and putting a Cloudflare JS Challenge on your afee.net/account page. What users would see is a “Verifying to see if you are a human” message which takes a second or two before your account page appears. I’ve found that to be very effective at stopping bots from making accounts, adding items to carts, and trying to check out.

I added a JS Challenge for the account area. What is the purpose of Turnstile then?

• This reply was modified 1 month, 3 weeks ago by nathaniel45.

I left my Turnstile on, but logically, at that point it is redundant. The JS Challenge downloads a 200K+ minified javascript and runs a whole series of complex calculations to determine if the requestor is a human or not.
You might leave the Turnstile for a while. If new bot accounts stop with the JS Challenge, you might try not using Turnstile.
I left my Turnstile on just to give the users another visual clue, but probably the JS Challenge is sufficient. My understanding is that it does a lot more verifying that you are a human than Turnstile. With Turnstile, if it has any doubts, it will have users verify by showing a box to click. JS Challenge doesn’t do that. It either determines you are a human or not.
I do see you have the JS Challenge on the account page.

Already had a bot get though and try to make a user account. I sure hope JS Challenge will improve blocking access more over time. I do have Turnstile on and will leave it. But it seems like a hidden input check is the best option as it works 100% of the time in blocking them.

• This reply was modified 1 month, 3 weeks ago by nathaniel45.
• This reply was modified 1 month, 3 weeks ago by nathaniel45.

And you know it’s a bot because?

It filled in the hidden input like they always do. JS Challenge seems to be working more then I first thought, out 26 issued only 5 solved.

• This reply was modified 1 month, 3 weeks ago by nathaniel45.
• This reply was modified 1 month, 3 weeks ago by nathaniel45.

What is your Cloudflare Super Bot Fight Mode configuration?

I’m only using the the free plan so I’m using the Bot Fight Mode.

OK. That might explain why I never see bots making accounts. I use the pro plan and have ‘definitely automated bots’ blocked in my Super Bot Fight Mode.

Even though people will see the black Cloudflare page briefly I’m hoping it stops most before they try making an account. But as stated they do not get though a simple hidden input honeypot. ! empty = no good.

• This reply was modified 1 month, 3 weeks ago by nathaniel45.

Not sure if any of these suggestions will help, but these are some ideas from ChatGTP:

Cloudflare’s JavaScript Challenge should block most bots because it requires JavaScript execution, which many automated bots cannot handle. However, if bots are still making accounts on your friend’s WordPress site, there are a few possible explanations:1. JS Challenge is Not Applied to All Registration Requests

• If the?JS Challenge is only applied to initial page loads?but not to the?actual form submission request, bots can bypass the challenge by directly sending requests to the registration endpoint (e.g.,?/wp-login.php?action=register?or a custom registration page).
• Solution: Ensure the?JS Challenge is enforced on both the page load and the form submission endpoint.

2. Session Persistence After Solving JS Challenge

• If Cloudflare’s?JS Challenge is solved once per IP, bots may?solve it once and then continue making registrations?without facing the challenge again.
• Solution: Use?Cloudflare Turnstile?(instead of or in addition to the JS Challenge) to enforce bot checks on?every form submission.

3. Bots Are Using Real Browsers or Puppeteer

• Advanced bots can?run JavaScript in a headless browser?(e.g.,?Puppeteer, Selenium, Playwright) to pass the JS Challenge.
• Solution: Use?Cloudflare Managed Challenge?instead, which detects browser automation techniques better than the JS Challenge.

4. Hidden Fields in the Registration Form

• If bots are?filling hidden fields, it suggests they are?not truly interacting with the page as a human would.
• Solution: Add?honeypot fields?that should remain empty and block form submissions if they are filled.

5. Cloudflare Challenge Mode is Too Lenient

• Your friend might have set the?JS Challenge to Low or Essentially Off, meaning only some requests are challenged.
• Solution: Set?Security Level to High?or create a?WAF rule to enforce JS Challenges on all registration requests.

Interesting… I’ll add a few extra pages to JS Challenge. I use woocommerce for user account area. My honey pot is as described in #4. I’ll also see if edits to the Challenge Mode is available in free Cloudflare. Thanks for the info.

My user account page is woocommerce too. These is my JS Challenge logic:

(http.request.uri.path eq “/checkout/”) or (http.request.uri.path eq “/my-account/”) or (http.request.uri.query contains “add-to-cart”) or (http.request.uri.path eq “/cart/”) or (http.request.method eq “POST” and http.request.uri.path contains “/product/”)

I have a few other conditions but those are unique to my site and my custom plugin.

And the action I have selected is JS Challenge.

I’m not sure how you are stopping them totally on your registration page as I had a few today and one just now try again. How many extra inputs do you have on your registration page? This client only wanted one extra “affiliation” extra then first and last name, email address and password. I noticed that the other clients I have are not spammed up like this but they ask many more questions.

Last night, I added to my code to tell me were the submission originated and it’s the account/ page. I just wanted to rule out them getting past the page. They would still have to crawl it as they are entering info in my honeypot. If the honeypot is hit the submission is blocked and I’m emailed a notice with what was entered and the IP address. “flagged bot new account registration {ip address here} entered: {a url they always enter}”

I just edited it from checking URI FULL to URI Path. Maybe that’s the trick.

• This reply was modified 1 month, 3 weeks ago by nathaniel45.

I think I may have figured out how they might be getting past and why the URI Path option might be best. It looks as if they are reaching the account/ page. They are using the this site as sub domain of the main set on the host. This is a new host and things are setup differently then my last. Looks like I have to block the sub domain using URI full.

It also turns out that Turnstile wasn’t working as that wasn’t the correct domain set for the key.

• This reply was modified 1 month, 3 weeks ago by nathaniel45.