#298 [URGENT] Account registration attempts with scraped emails lead to blacklisting Codeberg emails

Is it possible to provide an extra security challenge step if certain conditions are met?
Because there are email reputation services out there, haveibeenpwnd could be checked, things like that. It’s quite likely that if the address was scraped it’s on haveibeenpwnd.

Instead of blocking (possibly legitimate) users, one could then pose another step. “I hereby declare that I’m a real user” and post a second captcha or similar solution. That would most likely stop automated registering?

At least for the microsoft “galaxy” you could request access through this page:
https://sendersupport.olc.protection.outlook.com/snds/index.aspx

This will get you a warning when someone marks emails coming from IPs you control as spam.

It’s mostly a way to get informed AFAIK, it does not allow to appeal against any decision nor ask to be removed from any spam list.

The registration is (convoluted but) free as in gratis the person registering needs a microsoft account.

Do we keeps logs about registration attempts and the IPs they came from?

I like @sexybiggetje to re-think the registration process. How to take this a step further:

1. Manual approvals of registrations. This might annoy users and introduce additional work for us, but it would avoid scripted account creations.
2. Invite-based registrations and limit the number of invites per user per time unit.
3. Close “free” registration for a bit.

Do we keeps logs about registration attempts and the IPs they came from?

7 days as described in Terms of Use

@tklein23 I’m unfamiliar with the codebase (and go). I have tried looking at the gitea source to see what options there are. Looks like they don’t have a system of hooks there.

Option 1;
Is making multifactor authentication required an option? Or doesn’t Gitea provide that as a mandatory option during registration?

Option 2;

What’s involved with manual approving? Because we might turn on manual approving, and if possible create a system account that approves accounts on request via the API. (If the API provides an endpoint for this).

That we one could fire up a cronjob that does several things:

1. Check the e-mail address for reputation
2. Check the domain for reputation
3. Approve the request, or leave it open for manual tasks
4. Send custom mail to “support@codeberg” and “enduser” with a message akin to “We have choosen not to accept your registration because of the reputation services we use flagged your e-mail. If this is in error, please contact xyz”

This would still trigger some emails to those addresses, so this might not be the best alternative. But it could provide an extra step.

@sexybiggetje For the manual approval process you have described, could we prevent sending out mails if we modify the process to check the email reputation right when sending the registration form?

Because that way we could confine accounts with scraped email-adresses to “quarantine” and inform the user about that in the response page after sending their registration form instead of per mail triggered by cronjob. Accounts with good email reputation would not be sent to quarantine and instead would follow the regular registration-with-douple-opt-in process.

I think that could be possible but requires patching on Gitea. Or one would need to “trap” those emails in the SMTP server to prevent them from going out. But no clue how to achieve that.

I think this is a nice feature for gitea ... so all can benefit, if somebody has time to implement it

EDIT: I also like to have this for my instance ...

Option 1;
Is making multifactor authentication required an option? Or doesn’t Gitea provide that as a mandatory option during registration?

I like the idea of advertising the use of 2FA more prominently.

Option 2;

What’s involved with manual approving? Because we might turn on manual approving, and if possible create a system account that approves accounts on request via the API. (If the API provides an endpoint for this).

That we one could fire up a cronjob that does several things:

1. Check the e-mail address for reputation

Problem is that these registrations use valid email addresses of random people (who never heard about Codeberg or Gitea and thus think this is spam).