Login Form "Honey Pot" to Trap Bots
I recently went looking for an email form box script to use on a website and found one that had a "honey pot bot trap". I download the php files, and was reading up on it, I realized that these php files can be used in Login and Join forms, because it spoofs bots into seeing a form field to fill out that people cannot see. When it fills the form field, the php script then prevents the form from being executed. Someone might extend the concept to include a means to log the IP who fails to pass the test.
This could be one way to deal with bots, of which combined with a Captcha test, you have two levels of bot prevention. Anyways, I found this at the PHP Tutorial site.
-
I suspect this idea might already be used a lot seeing how some captcha's work in determining if a visitor is human.
-
Thanks Dannie!
You are correct, modern anti-bot tools use similar techniques. While users may think that captcha resolver is the only obstacle, the detection is actually a lot more complex. You may have noticed that some detectors don't even render captcha challenge anymore. Newer tools like Cloudflare Turnstile and Vercel BotID are almost entirely frictionless. Verification methods can be complex and they have to be frequently updated (including honeypots, keystrokes and cursor observers, timing tracking, form honeypots, pseudo elements, pattern matching, etc). We don't recommend using self-hosted captcha tests for that very reason - they don't protect from modern bots, and can in fact be a magnet for bots that seek out more vulnerable systems.
By the time v15 final is release we will have additional tools in AntiSpam app, most likely with BotID and potentially Turnstile integrations. We're also experimenting with Vercel bot management API in NEO app with the goal to provide it as a integrated metered service for UNA Pro subscribers.
-
Thank you, Andrey, for the insights. Another thing I found I thought was interesting, for an info and help website idea I am uploading, is a long list of banned "bad bots" that I have in an ,htaccess file. I think it has around 1814 bots that are banned. Some of the things you find online are surprising in terms of ideas you can use.
-
What is the rational for all the fake accounts that are created on UNA sites? Accounts which are never used?
Are they setting up for a future DOS attack?
-
Very often fake accounts are simply to have a profile that has spam content in description. Actual content publishing is more complex to orchestrate programmatically and gives away more red flag for the spam control tools to spot. The incentive usually is that spammers get paid for amount of mentions or backlinks they can create for a business, and so they try to post anywhere they can.
Standard workaround (besides captchas and paywalls) is to limit display of new and inactive profiles. You can for example limit visibility of profiles to authenticated only, or similar to how facebook does it - only show minimal Cover content publicly.
There is another angle where they create profiles that show business name + url/phone in the Name, which of course doesn't convert a link, but it is still an attack vector. You can limit max character for profile name to reduce the problem, and we're now working on an Agent which will use AI to assess profile names to auto-suspend spammy ones or enforce your community guidelines (i.e. real names only, no swear words, etc).
-
Great news Andrey—I can't wait for it to be finished...👍
-
Keep up the good work Andrey.
-
Hello, I created a custom contact form for my UNA website with honeypot and Cloudflare Turnstile protection. It was originally made just for my own use, but I thought it could potentially be useful for others too. It also comes with a few configurable options, such as separate recipient emails, submission timing, link limits, and rate limiting. Do you think there would be any interest in it?
-
I had some cool anti bot stuff years ago in a system that I was using at the time. I had a non visible form field that was populated with the word 'YES" when someone clicked a button to agree to terms during login. Validation just checked for not empty field. The form allowed the user to override the field manually. That test detected so many automated account creation scripts, it was just insane. Just filter for something other than YES and you've got a simple way to detect bots. The key was not to do a "fast fail" to let them know they were found - but just shadow ban the account and set an auto-delete in x days. BUT, This worked because it was my own system, that was unknown more broadly.
If UNA created a system, it would be a matter of time particuarly with open source code for the bot authors to determine how to delete the system and just put the word YES in that box. I agree that the best approach is third party turnstyle type systems that are able to change and react their detections as needed, without updating the site app is the beset approach. But either way, an interesting discussion.
-
Great News!
-
Nice work IMO!
