Added a blocker for sign-up spam
by FrankDoes anyone experience sign-up SPAM? I noticed many 'empty' sign-ups where new users joined but did not take any action, whatsoever. It became obvious that bots are running fake sign-ups.
Sharing a short description how to block the bots: https://medium.com/@frank42/spam-bots-and-fake-sign-ups-blocked-with-two-simple-tricks-5afffb9fd53c
-
1
Integrate Google captcha is as simpler to integrate (mostly the invisible captcha v3 that doesn't even display the button to check)
-
1
Thanks so much for sharing you experience. I've noticed a lot of bot/fake/empty sign ups recently on SaaSHub, and a lot of SPAM on LibHunt. I will implement both techniques this week. I feel like that could easily eliminate a lot of the buggers.
Timing the user input sounds so simple and smart! Kudos.
-
1
Good to see more people avoiding the dreaded and user-hostile Captcha. :) ARE you human, dear visitor?
The honeypot field technique tends to work exceedingly well. I've used it in the past for newsletter signups and it basically eliminated 99% of all bot spam submissions.
A third method that can help, if you are ok with breaking regular form submission behavior, is to handle your form submissions with JS to an API endpoint (since bots are again more unlikely to execute JS on these pages). Of course, that would also break form submissions for people with JS disabled by default, so that may not be advisable for everyone. :)
-
1
Honeypot technique seems promising , thanks for write-up.
-
1
Trick #1 does not work afaik. For example, I use Dashlane to handle all signup, registration and login forms. If Dashlane is not able to figure out how to fill the registration form, it's already a hard pass for me. Why? Because if it ain't able to fill the signup form, I can already assume the login form is coded in a really obscure and non-standard way. I have 4000+ accounts stored, all with different 16-21 character passwords. I will not handle my login for one site manually.
And do you go through all your signups manually? Is 500ms too fast? When do you start counting? At document ready? That could be 4 seconds in? Dashlane halts the dom and asks me what to do ... So most of the time my registration would be below 50-80ms ...
-
1
A workaround could be to store the page render start time in the user session (on the backend) and then check it again after submit, it wouldn't matter if Dashlane halts the DOM as there would be no JS involved.
-
1
didn't think of that before. I like it! :)
-
-
1
Of course, I would not go through all signups manually. Why on earth would anyone do that? The point is to have an automated approach. Whether 500ms is too fast anyone can decide specific to the website/service. Using a password manager to generate the password will smoothly work, it's an all-standard approach.
-
1
You'd be surprised on how many websites do signup and login forms in non-standard ways. :)
-
-
-
1
This comment was deleted 4 years ago.
