I think the only issue with that is if a user passes all bot checks, but then fails the captcha and you have the option "log passed events" on, it'll say the registration was allowed. A minor issue though, if there isn't a better solution I guess a compromise is necessary.
Yes, it's the only down side I can see. Sometimes in the logs, you might notice a user is a human and allowed to register through FBHP... but they seemed have been logged twice. On further investigation, you notice that the first attempted failed something in the registration. This is usually date of birth, non matching passwords, and sometimes the CAPTCHA. But, now if a human does fails the CAPTCHA, you won't be able to tell that from the logs. I don't think that's a big loss, what it more important is that you can tell that bots have passed/failed the CAPTCHA
I was also wondering, does everyone more or less get 14 altered fields from bots on average? The majority of bots I get tend to often alter this many fields. The weird thing is I have disabled fields that can be tabbed to option on, and the count was the same previously. This would seem to indicate that the bots didn't fall for that set of honey pot anyways.
Bots will look for the standard fields (the honey pots) "username, email, timezone, password, password_confirm" and try to populate them. After that, most bots will populate the next x fields in index order (formname[5], formname[6], etc.) with defined text. Most bots will be caught by 14 fields (the 5 standard honey pots, + 9 others). If your form contain custom fields near the beginning of the form, then it will be caught by less. For instance, if you add another 4 custom fields after the usename, most bots will then only be caught by 10 honeypots.
On average, >90% of the bots I've seen get caught by 14 honey pots, a handful 15 and some around 11-13.
These number aren't because they're getting around the honey pots, but because XRumer is often set to auto populate 20 fields
Of the standard honey pots: "username, email, timezone, password, password_confirm" Sometimes the bot wont get tripped up by email/username, since they don't populate it on the registration form, but let it pass through from the login page.. when they pick up the session cookie. So, the bot sometimes gets the username/email correct
If you disable the tabbed fields, one of the reasons you aren't seeing a difference, is not because the bot was bypassing them already, but because it's getting picked up by the next fields. There are currently a total of 24 hidden fields, most bots only bother to populate the 1st ~20 fields (6 real, 14 hidden + possibly 1 captcha), there are still another 10 hidden fields that they haven't even gotten to yet. If you had 1000 hidden fields, most botters would still only bother to populate the first 20 or so (it's not very common that a form would have more than 20 fields)
.. additionally, when you select the option "Disable Hidden Fields That Can Be Tabbed Into" you are actually converting one type of hidden field to another (so you don't actually lose any hidden fields, so the bots would still be caught by them)
Relating to this, I tried turning off captcha globally. As soon as I did it looked like a lot of bots suddenly only altered 2 or 3 fields
This I can't explain, other than every now and then you will get bots that target the standard fields only, so they will only get caught by 4-6 of the honey pots. 2 or 3 fields seems strange, what fields were they?
Dont forget, the javascipt mechanism is also a honey pot.. if they attempt to pass the wrong uuid through.. they get caught. If they don't attempt anything related to the js, they still get caught (but detecting bots via this mechanism is an ACP option that isn't even needed yet, since the hidden fields currently catch 100% of the bots)
And there is also the timer (which I expect to be beaten 2-3 months after it being introduced into the core, depending how large a target XenForo is). However, it was the weakest of all the mechanisms used in this plugin