Ratelimiting user logins #9874

New Issue

GiteaMirror · 2025-11-02T08:51:59-06:00

GiteaMirror commented

2025-11-02 08:51:59 -06:00

Originally created by @lunny on GitHub (Nov 23, 2022).

Feature Description

When a user inputs wrong password several times, Gitea should lock x minutes from that session to login again.

Screenshots

No response

Originally created by @lunny on GitHub (Nov 23, 2022). ### Feature Description When a user inputs wrong password several times, Gitea should lock x minutes from that session to login again. ### Screenshots _No response_

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

GiteaMirror commented

2025-11-02 08:52:00 -06:00

@silverwind commented on GitHub (Nov 23, 2022):

I suggest a high default like 10 logins in a 5 minute window because nothing is more obnoxious than when you're trying a few passwords that the site rate limits the retries too early. Ideally timeout should exponentially increase after limit is hit.

What should the limit be based upon? IP address?

@silverwind commented on GitHub (Nov 23, 2022): I suggest a high default like 10 logins in a 5 minute window because nothing is more obnoxious than when you're trying a few passwords that the site rate limits the retries too early. Ideally timeout should exponentially increase after limit is hit. What should the limit be based upon? IP address?

GiteaMirror commented

2025-11-02 08:52:01 -06:00

@techknowlogick commented on GitHub (Nov 23, 2022):

@silverwind yeah, IP because if you do it by username you could essentially lock out users by failing to log in as them a few times.

@techknowlogick commented on GitHub (Nov 23, 2022): @silverwind yeah, IP because if you do it by username you could essentially lock out users by failing to log in as them a few times.

GiteaMirror commented

2025-11-02 08:52:01 -06:00

@techknowlogick commented on GitHub (Nov 23, 2022):

I have a very rough PR for this here: https://github.com/go-gitea/gitea/pull/21181

Edit, oh lol I forgot you knew about that one already.

@techknowlogick commented on GitHub (Nov 23, 2022): I have a very rough PR for this here: https://github.com/go-gitea/gitea/pull/21181 Edit, oh lol I forgot you knew about that one already.

GiteaMirror commented

2025-11-02 08:52:01 -06:00

@silverwind commented on GitHub (Nov 23, 2022):

I totally forgot about that one 😉

@silverwind commented on GitHub (Nov 23, 2022): I totally forgot about that one 😉

GiteaMirror commented

2025-11-02 08:52:01 -06:00

@eloydegen commented on GitHub (May 31, 2023):

A CAPTCHA would be the best method in my view, otherwise there is still a risk of getting locked out by an attacker when something like Carrier Grade NAT is involved, although I'd see that as low risk.

@eloydegen commented on GitHub (May 31, 2023): A CAPTCHA would be the best method in my view, otherwise there is still a risk of getting locked out by an attacker when something like Carrier Grade NAT is involved, although I'd see that as low risk.

GiteaMirror commented

2025-11-02 08:52:02 -06:00

@lunny commented on GitHub (Jun 1, 2023):

Close since login with CAPTCHA has been implemented.

@lunny commented on GitHub (Jun 1, 2023): Close since login with CAPTCHA has been implemented.

GiteaMirror commented

2025-11-02 08:52:02 -06:00

@techknowlogick commented on GitHub (Jun 2, 2023):

CAPTCHAs aren't accessible, and so ratelimiting could provide an alternative

@techknowlogick commented on GitHub (Jun 2, 2023): CAPTCHAs aren't accessible, and so ratelimiting could provide an alternative

GiteaMirror commented

2025-11-02 08:52:02 -06:00

@silverwind commented on GitHub (Jun 8, 2023):

We can offer both options, yes.

@silverwind commented on GitHub (Jun 8, 2023): We can offer both options, yes.

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#9874