spam prevention through honeypots #5405

New Issue

GiteaMirror · 2025-11-02T06:23:58-06:00

GiteaMirror commented

2025-11-02 06:23:58 -06:00

Originally created by @thehowl on GitHub (May 15, 2020).

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

Originally created by @thehowl on GitHub (May 15, 2020). 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

GiteaMirror added the type/proposal topic/security labels 2025-11-02 06:23:58 -06:00

GiteaMirror commented

2025-11-02 06:23:58 -06:00

@fnetX commented on GitHub (Apr 26, 2021):

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 commented on GitHub (Apr 26, 2021): 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.

GiteaMirror commented

2025-11-02 06:23:58 -06:00

@fnetX commented on GitHub (Jul 9, 2021):

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 ...

@fnetX commented on GitHub (Jul 9, 2021): [A user on the Fediverse](https://dragonscave.space/@Mayana/106545050830010996) 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 ...

GiteaMirror commented

2025-11-02 06:23:59 -06:00

@f0x52 commented on GitHub (Aug 13, 2021):

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 commented on GitHub (Aug 13, 2021): 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 :/

GiteaMirror commented

2025-11-02 06:23:59 -06:00

@f0x52 commented on GitHub (Aug 14, 2021):

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

@f0x52 commented on GitHub (Aug 14, 2021): 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

GiteaMirror commented

2025-11-02 06:23:59 -06:00

@fnetX commented on GitHub (Nov 1, 2021):

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.

@fnetX commented on GitHub (Nov 1, 2021): 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.

GiteaMirror referenced this issue

2025-11-02 15:46:52 -06:00

[PR #5405] [MERGED] fix password variable shadowing #17786

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#5405