Spam account prevention #3059

New Issue

GiteaMirror · 2025-11-02T04:59:12-06:00

GiteaMirror commented

2025-11-02 04:59:12 -06:00

Originally created by @chr-1x on GitHub (Mar 17, 2019).

Gitea version (or commit ref):
1.7.4 built with go1.12 : bindata, sqlite, sqlite_unlock_notify
Git version:
2.17.1
Operating system: Ubuntu 16.04
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist:

Description

I was just flooded with bounced emails from spam accounts that had signed up on my Gitea instance, all on yandex.ru or yandex.com. The accounts in question were mostly not activated (since the emails used were not, apparently, real email addresses) and almost all following a particular naming convention. I went through and deleted all the spam accounts and there were a good 30 or so in total.

Gitea needs some better spam prevention tools. Checking email addresses for validity and blacklisting certain email providers are bare minimums that other server software provides, and additionally being able to prune non-activated accounts is a common measure that helps with spam prevention.

Screenshots

N/A

Originally created by @chr-1x on GitHub (Mar 17, 2019). - Gitea version (or commit ref): 1.7.4 built with go1.12 : bindata, sqlite, sqlite_unlock_notify - Git version: 2.17.1 - Operating system: Ubuntu 16.04 - Database (use `[x]`): - [x] PostgreSQL - [ ] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant - Log gist: ## Description I was just flooded with bounced emails from spam accounts that had signed up on my Gitea instance, all on yandex.ru or yandex.com. The accounts in question were mostly not activated (since the emails used were not, apparently, real email addresses) and almost all following a particular naming convention. I went through and deleted all the spam accounts and there were a good 30 or so in total. Gitea needs some better spam prevention tools. Checking email addresses for validity and blacklisting certain email providers are bare minimums that other server software provides, and additionally being able to prune non-activated accounts is a common measure that helps with spam prevention. ## Screenshots N/A

GiteaMirror added the type/question issue/stale labels 2025-11-02 04:59:12 -06:00

GiteaMirror closed this issue

2025-11-02 04:59:13 -06:00

GiteaMirror commented

2025-11-02 04:59:13 -06:00

@adelowo commented on GitHub (Mar 18, 2019):

You can do this with the config value EMAIL_DOMAIN_WHITELIST

[service]
EMAIL_DOMAIN_WHITELIST=gmail.com,mywebsite.com

@adelowo commented on GitHub (Mar 18, 2019): You can do this with the config value `EMAIL_DOMAIN_WHITELIST` ``` [service] EMAIL_DOMAIN_WHITELIST=gmail.com,mywebsite.com ```

GiteaMirror commented

2025-11-02 04:59:13 -06:00

@chr-1x commented on GitHub (Mar 18, 2019):

I would prefer not to whitelist, many of my users (who are using my server because they prefer decentralized servers) have their own mail domains and I don't want to require each new user to contact me first (or if I did, an email address rejection would not be a very welcoming way to do so)

@chr-1x commented on GitHub (Mar 18, 2019): I would prefer not to whitelist, many of my users (who are using my server because they prefer decentralized servers) have their own mail domains and I don't want to require each new user to contact me first (or if I did, an email address rejection would not be a very welcoming way to do so)

GiteaMirror commented

2025-11-02 04:59:14 -06:00

@mrsdizzie commented on GitHub (Mar 18, 2019):

Probably a few separate issues in here:

For general combating of these types of signups, there is a CAPTCHA option that should help prevent automation of spam accounts if not already using that (any public facing form definitely needs this, unfortunately):

[service]
ENABLE_CAPTCHA: false: Enable this to use captcha validation for registration.
CAPTCHA_TYPE: image: [image, recaptcha]
RECAPTCHA_SECRET: ””: Go to https://www.google.com/recaptcha/admin to get a secret for recaptcha.
RECAPTCHA_SITEKEY: ””: Go to https://www.google.com/recaptcha/admin to get a sitekey for recaptcha.

You can also use fail2ban similarly as described at https://docs.gitea.io/en-us/fail2ban-setup/ but monitoring for POSTS to the signup form instead, which look like this in the http log:

Started POST /user/sign_up for [ip address]

fail2ban is probably also something that any public facing service should be using as well.

I don't think gitea should be responsible for blacklisting any providers, but it seems possible to offer an EMAIL_DOMAIN_BLACKLIST if also offering a WHITELIST. There is already general email address validation on the form, so not exactly sure what the issue is there (probably just not clear what you mean by validation). FWIW this will eventually just happen with @gmail.com addresses as well so a blacklist only goes so far and the other measures above are more helpful in real world situations.

I don't there isn't really anything outside of direct SQL or scripting API calls that can manage users in bulk and delete non-activated accounts. The Web interface doesn't seem designed for making changes to multiple users at once. There also need to be more options for the command line. Particularly this situation would benefit both an option to list users based on certain field matching (last logged in = never) and to be able to delete users as well.

@mrsdizzie commented on GitHub (Mar 18, 2019): Probably a few separate issues in here: For general combating of these types of signups, there is a CAPTCHA option that should help prevent automation of spam accounts if not already using that (any public facing form definitely needs this, unfortunately): ``` [service] ENABLE_CAPTCHA: false: Enable this to use captcha validation for registration. CAPTCHA_TYPE: image: [image, recaptcha] RECAPTCHA_SECRET: ””: Go to https://www.google.com/recaptcha/admin to get a secret for recaptcha. RECAPTCHA_SITEKEY: ””: Go to https://www.google.com/recaptcha/admin to get a sitekey for recaptcha. ``` You can also use fail2ban similarly as described at https://docs.gitea.io/en-us/fail2ban-setup/ but monitoring for POSTS to the signup form instead, which look like this in the http log: ``` Started POST /user/sign_up for [ip address] ``` fail2ban is probably also something that any public facing service should be using as well. I don't think gitea should be responsible for blacklisting any providers, but it seems possible to offer an EMAIL_DOMAIN_BLACKLIST if also offering a WHITELIST. There is already general email address validation on the form, so not exactly sure what the issue is there (probably just not clear what you mean by validation). FWIW this will eventually just happen with @gmail.com addresses as well so a blacklist only goes so far and the other measures above are more helpful in real world situations. I don't there isn't really anything outside of direct SQL or scripting API calls that can manage users in bulk and delete non-activated accounts. The Web interface doesn't seem designed for making changes to multiple users at once. There also need to be more options for the command line. Particularly this situation would benefit both an option to list users based on certain field matching (last logged in = never) and to be able to delete users as well.

GiteaMirror commented

2025-11-02 04:59:14 -06:00

@lunny commented on GitHub (Mar 18, 2019):

You could enable register email confirmation.

[service]
; Time limit to confirm account/email registration
ACTIVE_CODE_LIVE_MINUTES = 180
; Time limit to perform the reset of a forgotten password
RESET_PASSWD_CODE_LIVE_MINUTES = 180
; Whether a new user needs to confirm their email when registering.
REGISTER_EMAIL_CONFIRM = true

@lunny commented on GitHub (Mar 18, 2019): You could enable register email confirmation. ```ini [service] ; Time limit to confirm account/email registration ACTIVE_CODE_LIVE_MINUTES = 180 ; Time limit to perform the reset of a forgotten password RESET_PASSWD_CODE_LIVE_MINUTES = 180 ; Whether a new user needs to confirm their email when registering. REGISTER_EMAIL_CONFIRM = true ```

GiteaMirror commented

2025-11-02 04:59:14 -06:00

@stale[bot] commented on GitHub (May 17, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (May 17, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

2025-11-02 04:59:14 -06:00

@stale[bot] commented on GitHub (May 31, 2019):

This issue has been automatically closed because of inactivity. You can re-open it if needed.

@stale[bot] commented on GitHub (May 31, 2019): This issue has been automatically closed because of inactivity. You can re-open it if needed.

GiteaMirror referenced this issue

2025-11-02 12:17:51 -06:00

[PR #3059] [MERGED] Delete a user's public key via admin api (closes #3014) #16737

Sign in to join this conversation.