Hi there,
Could you help me out with a solution in SMF (2.1.4) for adding a honeypot to the registration form specifically for the email field? I'm looking for a clever way to handle this.
For Spam Bots:
Currently, there's a standard email field:
<input type="email" name="email" id="smf_autov_reserve1" size="50" tabindex="2" value="">This field should be kept as a honeypot, meaning it will be hidden from users using CSS (but spam bots will still automatically fill it out).
For Users:
For actual users, a different visible and functional email field will be shown, for example:
<input type="login2" name="login2" id="smf_autov_reserve2" size="50" tabindex="2" value="">This field will function normally for users to input their email during registration.
How it works:
When users register, they see all the necessary fields in their browser and fill them out, allowing them to register successfully as usual. However, when a spam bot registers, it fills out all the fields, including the one hidden by CSS. After the bot submits the form, it should receive a (fake) ;) message saying, "Registration successful! To activate your account, please click the link sent to your email."
Waste of time. If they're already defeating the existing honey pot, a second one isn't going to help especially given the existing honey pot is smarter than this.
Thanks for your opinion. But I asked for a solution for my forum.
And I'm pointing out that this solution isn't going to help you because there's already an empty form field on the registration form as a honey pot. And the field's name is not consistent to defeat bots that are programmed for it.
The reality is that bots today are smarter than ever: they are capable of figuring out which fields are visible and only populating those. At best you make it harder for people using assistive technologies (not least password managers) and not defeat any extra bots.
The stupid bots already get caught by the (multiple) silent methods during registration, and the smart ones will sail right through like they do today.
I mean, I'm only the person who hardened the registration form in multiple ways in 2.1 including adding the honeypot that is already there, I'm sure I wouldn't know.
I mean, I never ran a honeypot for years collecting data about what bots actually do - like the ones who used to beat SMF's CAPTCHA by using the audio CAPTCHA as that was easier to solve for a while until the OCR techniques got better, though very few ever got through the animated CAPTCHA I trialled, and of those I'm fairly sure most were humans registering on behalf of a spam service. Which will get through your honeypot with zero difficulty.
Quote from: Butiks on August 29, 2024, 09:59:03 AMThanks for your opinion. But I asked for a solution for my forum.
and you were given reasons why the "solution" that you were asking for would not work.
We practice intelligent assistance here -- we don't just hand people whatever they ask for -- we help people figure out what the best way to accomplish the END GOAL is (which is, quite often, *NOT* the "assumed" way that the person first asks for)
The best protection is questions, usually related to the page. For example, you can set one news to show to unregistered users and enter some code there. And the question is about finding the secret code at the top of the page.
Even AI will probably go crazy.
Questions have long been the best tool we have (this is why 2.1 got updated questions support to cover multiple languages, multiple variant answers per question etc)
But even then you need to change the questions every so often, and not have ones that are easily solved just by asking Google (or ChatGPT), because a) bots can and do ask these services for answers, and b) there is a mostly-central database of questions and answers maintained by the bot spam tools. Only takes one human to go through and answer the question...
This is also why asking multiple questions at once is a useful technique.