![[TAC] Fool Bot Honey Pot](/community/data/resource_icons/1/1085.jpg?1577367167){kind=icon}
[TAC] Fool Bot Honey Pot [Paid] 3.0.32
- Thread starter tenants
- Start date
tenants
Well-known member
@woei
Hmm, even password managers should get reset
... So, usually password managers, although they are prevented, they are not detected as bots
A password manager will, as you suggest, try to complete all of the hidden fields, but these users are still human,
So what I do, is reset all the hidden honey-pot fields, once the page is loaded (making password managers ineffective, but also not detecting them as bots)
Can you send me a link to your password manager, so that I can test it
The fields are correctly being reset (with/without password managers, I wonder if your password manager tries to set on send)
If this is the case, I can try to reset on send too
Last edited:
tenants
Well-known member
@woei
Can you try registering using your password manager again
(Don't worry about duplicate accounts, just see if you can trigger the bot detection with your password manager)
What I now do, is not only reset the passwords/usernames on page load (to avoid password manager issues), but also on form submit (since it looks like this is when it got set by your password manager.. strange, I thought they always set them on page load)
So now, on clicking form->submit, even if your password manager tries to "set" the hidden password, it shouldn't do anything
This wont affect bots (they will still correctly be detected)
Can you try registering using your password manager again
(Don't worry about duplicate accounts, just see if you can trigger the bot detection with your password manager)
What I now do, is not only reset the passwords/usernames on page load (to avoid password manager issues), but also on form submit (since it looks like this is when it got set by your password manager.. strange, I thought they always set them on page load)
So now, on clicking form->submit, even if your password manager tries to "set" the hidden password, it shouldn't do anything
This wont affect bots (they will still correctly be detected)
tenants
Well-known member
tenants updated FoolBotHoneyPot Bot Killer: Spam Combat with a new update entry:
more robust - avoid password manager detection
Read the rest of this update entry...
more robust - avoid password manager detection
Read the rest of this update entry...
tenants
Well-known member
Well, only human spammers
The logs get automatically cleared up weekly, so you don't have to delete them
No more than 3 months of logs should be added (since, it's quite unlikely admins will want to look at logs more than 3 months old)
Last edited:
tenants
Well-known member
@woei
I now know why this might have crept in (and not been an issue before), it's to do with the template modifications changes I've made
I should have also added: "autocomplete = off" to the form to avoid password managers
... although the above changes will harden the case for password managers (when "autocomplete = off" is ignored ... some browsers and some password manager do this, but shouldn't!), I should really add "autocomplete = off" back to the form using template modifications too.
I will make another update soon
I now know why this might have crept in (and not been an issue before), it's to do with the template modifications changes I've made
I should have also added: "autocomplete = off" to the form to avoid password managers
... although the above changes will harden the case for password managers (when "autocomplete = off" is ignored ... some browsers and some password manager do this, but shouldn't!), I should really add "autocomplete = off" back to the form using template modifications too.
I will make another update soon
tenants
Well-known member
tenants updated FoolBotHoneyPot Bot Killer: Spam Combat with a new update entry:
AUTOCOMPLETE off re-added
Read the rest of this update entry...
Since I really want to avoid false positives, the case for password managers was always 2 fold
- Password managers should never have set the hidden passwords, since the form uses auto-complete=off, but some password managers broke this rule. So, what I also did is reset the passwords on page load... that was fine, but recently I made a change that missed the "auto-complete=off". In doing this, I found a weakness with resetting the password on page load.. some password managers actually seem to set the password after the page-load reset had been carried out.
I've hardened this, so that passwords are now also reset on form submit and re-added the auto-complete=off to the forum
... So not only, users using password managers should never be detected again, this is once again 2 fold and this time hardened. (It would be very hard for even a password manager that breaks all the rules to change the hidden fields now)
... So we should be back in the 0% false positives 100% bot detection area (even when users use password managers)
AUTOCOMPLETE off re-added
Read the rest of this update entry...
Since I really want to avoid false positives, the case for password managers was always 2 fold
- Password managers should never have set the hidden passwords, since the form uses auto-complete=off, but some password managers broke this rule. So, what I also did is reset the passwords on page load... that was fine, but recently I made a change that missed the "auto-complete=off". In doing this, I found a weakness with resetting the password on page load.. some password managers actually seem to set the password after the page-load reset had been carried out.
I've hardened this, so that passwords are now also reset on form submit and re-added the auto-complete=off to the forum
... So not only, users using password managers should never be detected again, this is once again 2 fold and this time hardened. (It would be very hard for even a password manager that breaks all the rules to change the hidden fields now)
... So we should be back in the 0% false positives 100% bot detection area (even when users use password managers)
Last edited:
woei
Well-known member
I have done so (you can delete the account woeitest) and this time it went ok. Thanks for updating.
Brent W
Well-known member
Can you please either remove the registration timer feature or make it so that it is not reset to default on updates? I am not sure what update it was but one of them reset the registration timer in the add-on to 7. I want to only use the default xenForo option. Not sure why both need to exist now? What happens if both have numbers filled out?
tenants
Well-known member
I haven't removed it yet, but there is no negative impact
Both the core and fbhp use a timer method that can not easily be faked
Every timer I've seen so far can be manipulated using man-in-the-middle/resending the request string with an application (but not the core or fbhp), so a pat on the back for xf getting that right
- Setting both core and FBHP won't cause an issue, which ever has the highest value will simply get hit by the bots first
The reason I haven't removed it, is because it's good to see the details in the fbhp logs, but should I get round to it, I will just pull that information from the core timer
However, if you also consider that the core is always targeted (add-ons less so), if there was a way to manipulate the session cache...(I don't know how, maybe cookie manipulation to set the session timer, but I don't think that that is possible), it might be possible to get around the core timer, but the fbhp timer will remain in-tact (since it is less likely to be targeted). I suspect however, the way they will eventually get around timer is simply by delay request (so waiting 25 seconds like a human), in which case all timers will be void
so
1) There is no need (no negative impact)
2) It's nice to see the info the logs (but could pull info from the core)
3) I'm lazy (I'm lazy)
4) If there is a way around the core, it's possible fbhp timer will still work (although I suspect if this happens, all timers will be void)
Both the core and fbhp use a timer method that can not easily be faked
Every timer I've seen so far can be manipulated using man-in-the-middle/resending the request string with an application (but not the core or fbhp), so a pat on the back for xf getting that right
- Setting both core and FBHP won't cause an issue, which ever has the highest value will simply get hit by the bots first
The reason I haven't removed it, is because it's good to see the details in the fbhp logs, but should I get round to it, I will just pull that information from the core timer
However, if you also consider that the core is always targeted (add-ons less so), if there was a way to manipulate the session cache...(I don't know how, maybe cookie manipulation to set the session timer, but I don't think that that is possible), it might be possible to get around the core timer, but the fbhp timer will remain in-tact (since it is less likely to be targeted). I suspect however, the way they will eventually get around timer is simply by delay request (so waiting 25 seconds like a human), in which case all timers will be void
so
1) There is no need (no negative impact)
2) It's nice to see the info the logs (but could pull info from the core)
3) I'm lazy (I'm lazy)
4) If there is a way around the core, it's possible fbhp timer will still work (although I suspect if this happens, all timers will be void)
Last edited:
tenants
Well-known member
tenants updated FoolBotHoneyPot Bot Killer: Spam Combat with a new update entry:
Reduce Brute Force Impact
Read the rest of this update entry...
Reduce Brute Force Impact
Read the rest of this update entry...
Last edited:
tenants
Well-known member
For bots that keep re-attempting, have no js, have altered hidden fields and have tried to register very fast, the default page they will now see is this:
This is a 0 query method and low byte usage (not just 0 query overhead, buy actually 0 queries)
This should significantly reduce the impact of bots that hammer the registration page
You can optionally redirect them to a site page of your choice (but I would recommend leaving the redirect blank and just allowing the 0 query 401)
- Note, the 401 message is not the page bots / humans will see if they are not repeatedly detected as a bot, instead they will usually see this page on 1st detection:
This is a 0 query method and low byte usage (not just 0 query overhead, buy actually 0 queries)
This should significantly reduce the impact of bots that hammer the registration page
You can optionally redirect them to a site page of your choice (but I would recommend leaving the redirect blank and just allowing the 0 query 401)
- Note, the 401 message is not the page bots / humans will see if they are not repeatedly detected as a bot, instead they will usually see this page on 1st detection:
Last edited: