Login Captcha #2900

New Issue

GiteaMirror · 2025-11-02T04:53:09-06:00

GiteaMirror commented

2025-11-02 04:53:09 -06:00

Originally created by @metiftikci on GitHub (Feb 12, 2019).

How about login captcha?

Force to solve captcha if user tried to login 3 times with wrong password.

Originally created by @metiftikci on GitHub (Feb 12, 2019). How about login captcha? Force to solve captcha if user tried to login 3 times with wrong password.

GiteaMirror added the type/proposal topic/security labels 2025-11-02 04:53:09 -06:00

GiteaMirror closed this issue

2025-11-02 04:53:09 -06:00

GiteaMirror commented

2025-11-02 04:53:09 -06:00

@savavirtosu commented on GitHub (Oct 16, 2019):

Here is a potential development plan for solving the current issue:

Add to User model a new column LoginAttempts.
Every time a user provides a wrong password on the sign in, the LoginAttempts is incremented.
Every time a user provides a valid password on the sign in, the LoginAttempts is set to 0.

If the LoginAttempts become bigger than X, in the sign in form a new captcha field will appear.

I think we could use the existing configuration flag in order to know if we should force captcha checking after X failed attempts.
Also, I think that the number of failed login attempts X could be hardcoded to 5 directly in code.

@savavirtosu commented on GitHub (Oct 16, 2019): Here is a potential development plan for solving the current issue: Add to User model a new column `LoginAttempts`. Every time a user provides a wrong password on the sign in, the LoginAttempts is incremented. Every time a user provides a valid password on the sign in, the LoginAttempts is set to 0. If the LoginAttempts become bigger than X, in the sign in form a new captcha field will appear. ![image](https://user-images.githubusercontent.com/1003758/66957920-09e3e380-f05f-11e9-9f57-6b8226a03602.png) I think we could use the existing [configuration flag](https://github.com/go-gitea/gitea/blob/14f16d6c2e8db1d99268c44a59aa86132c00eca3/snap/helpers/app.ini#L49) in order to know if we should force captcha checking after X failed attempts. Also, I think that the number of failed login attempts X could be hardcoded to 5 directly in code.

GiteaMirror commented

2025-11-02 04:53:10 -06:00

@lunny commented on GitHub (Oct 17, 2019):

@savionok I think a new column in user table is unnecessary. But the LoginAttempts could be saved in session.

@lunny commented on GitHub (Oct 17, 2019): @savionok I think a new column in `user` table is unnecessary. But the `LoginAttempts` could be saved in session.

GiteaMirror commented

2025-11-02 04:53:10 -06:00

@guillep2k commented on GitHub (Oct 17, 2019):

@lunny if we are trying to stop a hack attempt by putting a captcha and reducing the odds that it's a robot attempt, we should not trust the session cookies, I believe. 🤔

@guillep2k commented on GitHub (Oct 17, 2019): @lunny if we are trying to stop a hack attempt by putting a captcha and reducing the odds that it's a robot attempt, we should not trust the session cookies, I believe. 🤔

GiteaMirror commented

2025-11-02 04:53:10 -06:00

@lunny commented on GitHub (Oct 17, 2019):

@guillep2k Currently we allow one user login serval times, maybe one for your personal computer, one for working computer and one for your mobile. So store it on database one column will result in other things. If we want to do that, we needs a device management table. Of course we can do that for a long consideration.

We have depended on session cookies on login I think. Once you have a different cookie value when you logined, you will be logout.

@lunny commented on GitHub (Oct 17, 2019): @guillep2k Currently we allow one user login serval times, maybe one for your personal computer, one for working computer and one for your mobile. So store it on database one column will result in other things. If we want to do that, we needs a device management table. Of course we can do that for a long consideration. We have depended on session cookies on login I think. Once you have a different cookie value when you logined, you will be logout.

GiteaMirror commented

2025-11-02 04:53:10 -06:00

@guillep2k commented on GitHub (Oct 17, 2019):

@lunny Captchas are normally meant to tell humans from robots that can be doing a dictionary attack. If that's not our intention, why use a captcha at all? Robots will certainly not honor session cookies. 👾

Any cookies kept in the real user's computers should not be affected in any way. If they were valid, they should remain valid. No problems there.

As I understand it, the LoginAttempts column is actually meant to count login failures, not attempts (it should be named LoginFailures instead). It shouldn't affect the normal workflow of the real user, even if they use fifteen computers. If the real user logs in from another computer when LoginAttempts is maxed out, the login failure count will simply be reset to zero, even if the "robot" is failing repeatedly, but that would only give the robot three more tries. It may require the user to pass the captcha, but that's very good: knowing that someone else is trying to hack our account! 😱

Tools like RSS readers or even git's HTTP protocol will not be affected by this because they don't use the login form.

@guillep2k commented on GitHub (Oct 17, 2019): @lunny Captchas are normally meant to tell humans from robots that can be doing a dictionary attack. If that's not our intention, why use a captcha at all? Robots will certainly not honor session cookies. 👾 Any cookies kept in the real user's computers should not be affected in any way. If they were valid, they should remain valid. No problems there. As I understand it, the `LoginAttempts` column is actually meant to count login failures, not attempts (it should be named `LoginFailures` instead). It shouldn't affect the normal workflow of the real user, even if they use fifteen computers. If the real user logs in from another computer when `LoginAttempts` is maxed out, the login failure count will simply be reset to zero, even if the "robot" is failing repeatedly, but that would only give the robot three more tries. It may require the user to pass the captcha, but that's very good: knowing that someone else is trying to hack our account! 😱 Tools like RSS readers or even git's HTTP protocol will not be affected by this because they don't use the login form.

GiteaMirror commented

2025-11-02 04:53:11 -06:00

@lafriks commented on GitHub (Oct 17, 2019):

I agree @guillep2k this can be global per user and reset to zero on successful authorization

@lafriks commented on GitHub (Oct 17, 2019): I agree @guillep2k this can be global per user and reset to zero on successful authorization

GiteaMirror commented

2025-11-02 04:53:11 -06:00

@lafriks commented on GitHub (Oct 17, 2019):

We should probably also keep last failed authorization timestamp so that we can discard failure count after x minutes has passed

@lafriks commented on GitHub (Oct 17, 2019): We should probably also keep last failed authorization timestamp so that we can discard failure count after x minutes has passed

GiteaMirror commented

2025-11-02 04:53:11 -06:00

@GAS85 commented on GitHub (Jul 25, 2022):

What about this nice feature? Seems really useful. I would add, that admin should be able to configure login attempts to 0 that should drive to show captcha on each login attempt.

How about not existing users attempts?
That should be kind of option to track Session, IP and show Captcha to those user.

@GAS85 commented on GitHub (Jul 25, 2022): What about this nice feature? Seems really useful. I would add, that admin should be able to configure login attempts to 0 that should drive to show captcha on each login attempt. How about not existing users attempts? That should be kind of option to track Session, IP and show Captcha to those user.

GiteaMirror commented

2025-11-02 04:53:11 -06:00

@hiqsociety commented on GitHub (Oct 1, 2022):

i prefer a captcha just for login.
i mean to login, solve captcha.
when can this be implemented?

@hiqsociety commented on GitHub (Oct 1, 2022): i prefer a captcha just for login. i mean to login, solve captcha. when can this be implemented?

GiteaMirror commented

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

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

Closed as #21906 opened.

@lunny commented on GitHub (Nov 23, 2022): Closed as #21906 opened.

GiteaMirror referenced this issue

2025-11-02 12:15:35 -06:00