spam prevention through honeypots

[thehowl]

I host a public Gitea instance, but an incredible amount of users are actually spambots, even though I have reCAPTCHA added on the website in an attempt to reduce the spam. For this reason, I think there needs to be honeypots in the sign-up form, which are a better way to prevent spam, and I think they should be enabled by default.

For those who don't know, the rationale is this: in the sign-up forms, have fields that only bots will fill in. These could be form inputs with type="text" name="email" style="display: none;" for instance, while the real email input is type="text" name="kjnjnj1199i__". Once we see on the server side that the email field has been submitted, we understand that the user is actually a bot (at this point, we may decide to ipban the user).

Here is a list of resources regarding it: https://github.com/paralax/awesome-honeypots

[fnetX]

What about accessibility? Will modern screen readers and other assistive technologies respect the display: none;, while bots keep falling into the trap? There are more effective honey pot things like using more css tricks to hide the content (move it out of the screen, reduce height, change opacity etc), but I read that most of them are a killer for screen readers and the like.

Please make sure to unmistakably indicate that the field should not be filled out.

[fnetX]

A user on the Fediverse offered to test a proof of concept etc, and they said the contact form at this page using a visible honeypot works fine: https://a.www.pdgo.com/contact/

This sounds like a good thing to try.

Another interesting thing: How to protect against targeted registrations? They probably know how to fill the form and what to leave empty, so they won't be stopped by a captcha ... Hmm ...

[f0x52]

I just wrote https://git.pixie.town/f0x/gitea-registration-proxy to try this out, but with N=1 found a spam signup that happily used the new signup template right away, so imo it's very likely these spam signups happen (manually!) through a browser.

I'll update this if it turns out this does block a significant amount of attempts, but so far it looks a bit bleak :/

[f0x52]

My hidden field attempt was too simple and easily bypassed, but there might be some merit in this still. For my proxy I added a field to fill in a Haiku, with syllable counting on the backend.
Interestingly, the vast majority of bots filled in "Muchas gracias. ?Como puedo iniciar sesion?", which from some googling seems very prevalent in spam flooding. It's not a valid Haiku of course, so this system seems to work well for my instance

[fnetX]

The big question is probably what to fight. Honey pots prevent automatic spam registrations that register on every website. We see a lot of this on our Gitea instance, spam accounts that probably try to abuse the ranking to improve their SEO score.

Another option that comes to my mind are dropdowns, they are seen on some smaller sites like https://cgi.tilde.town/users/signup, I wonder if they work out. Of course, I still think this doesn't really help against targeted registrations (scripts that are specific for Gitea), but I think it might be good a consideration.