I have a request/suggestion:

Spammers could fix their bots to look for the honeypot-textfield class, and ignore putting text in the hidden field on any site that uses the honeypot.

You might want to have the module create a 20 or so character random string on installation, and save it in a variable in the database. Then, use that variable in the CSS class name in the module from then on. That way, bots could not be configured to find your class name and simply ignore the text field on all sites that use your module.

CommentFileSizeAuthor
#5 honeypot-css_classes_accessibility_autocomplete-1489304.patch1.11 KBhles

Comments

geerlingguy’s picture

geerlingguy commented
Version: 6.x-1.x-dev » 7.x-1.x-dev

I could also just use the site name, sanitized, or some other string specific to the site. But I get exactly what you're saying; any extra step to obfuscate the field from dedicated spammers is a step worth taking...

New features go into D7 first :)

gregarios’s picture

gregarios commented

Yes, although using the site name alone could be code-able on the spammers' side, too. Only random is truly unpredictable.

geerlingguy’s picture

geerlingguy commented

Yes, but if it's just generated once, then it would be just as random as the site name, since neither the random string nor the site name would ever change :)

At least with the site name, we wouldn't need to add another variable or data point to the site...

gregarios’s picture

gregarios commented

But bots are coded to identify the string on thousands of sites -- they will never code each sites string one at a time. ;-)

If it is the site's name, it can be predicted, and therefore identified on everyone's site. If it is random, there is no way to predict what the next site's string will be, do it isn't identifiable. And, it needs to be generated just once per site so it can be cached.

hles’s picture

hles commented
Component: Miscellaneous » Code
StatusFileSize
new honeypot-css_classes_accessibility_autocomplete-1489304.patch1.11 KB

I think it should not contain honeypot as well. But instead of generating a random string on installation, maybe it's better to use dictionary words because what we actually want is that the field looks real to bots, so it fills it in. The settings already allow you to choose a word of your choice (by default homepage), so maybe we can use it in the CSS class as well.

On another matter, screen readers sometimes ignore display:none, so we should add visibility:hidden; as well.
We should also use autocomplete: off so when client's autocomplete is enabled, we are sure it does not fill in the field.
I know this should be in other issues, but these are minor changes and all grouped in the honeypot element creation.

geerlingguy’s picture

geerlingguy commented
Status: Active » Needs review

Sounds reasonable. I like the patch, will test (anyone else can too :), and might spare a few minutes during DrupalCon to roll it into -dev. Probably won't create a new release for a couple weeks.

gregarios’s picture

gregarios commented
Status: Needs review » Active

Agree on all that.

Another thing I noticed, since we're talking small issues, is that the caching of the page could still be allowed if you had an external non-cached javascript file supply the code for the hidden field in the page. That way, the page can be cached, and the browser will still load the field via javascript with the correct time stamp in it. Currently, Boost can still cache the form page, and the timestamp gets very old. This doesn't affect how the form works, but only the first person (or bot) to cause the static page cache to be built has an accurate waiting period. All other users of the cached page arrive to an already expired timestamped page.

Adding the field via javascript also could ensure that non-javascript enabled bots fail every time.

I use a similar thing to make a server-time generated javascript clock on all my pages... and it works whether the page is static-cached or not. :-)

Just an idea.

geerlingguy’s picture

geerlingguy commented

If you had an external non-cached javascript file supply the code for the hidden field in the page

The problem is, we use Drupal's Form API to process/validate the field value, and we can't use JavaScript to put new field values in the form (unless I'm mistaken), and it seems that kind of thing would be a security risk anyways. The other things mentioned in this thread are doable, though.

geerlingguy’s picture

geerlingguy commented
Status: Active » Fixed

Committed modified patch from #5 (I like that approach, and it lets admins easily choose a unique field/class without resorting to a random string/non-dictionary word): http://drupalcode.org/project/honeypot.git/commit/dc233d1

With regard to "Adding the field via javascript also could ensure that non-javascript enabled bots fail every time.", if you're interested in pursuing this option, please open a new issue... I just don't think it's too practical unless we don't use Form API, and that would be a bit of a challenge.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

(not verified) commented
Issue summary: View changes

Grammer correction.