Ability to enforce two-factor authentication #333

@stale[bot] commented on GitHub (Feb 3, 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 (Feb 3, 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

@9thWonderAgency commented on GitHub (Jul 25, 2019):

I am but a simple Gitea user, would like to voice that my organization would also find this a very important feature. Please!

@9thWonderAgency commented on GitHub (Jul 25, 2019): I am but a simple Gitea user, would like to voice that my organization would also find this a very important feature. Please!

GiteaMirror commented

@zeripath commented on GitHub (Jan 29, 2020):

Ok if we're gonna do this we need to think about what happens if a user tries to login without two factor.

Is it that they get redirected immediately to the enroll 2fa page similar to the must change password screen?

@zeripath commented on GitHub (Jan 29, 2020): Ok if we're gonna do this we need to think about what happens if a user tries to login without two factor. Is it that they get redirected immediately to the enroll 2fa page similar to the must change password screen?

GiteaMirror commented

@tomposmiko commented on GitHub (Apr 17, 2020):

It would already be enough if we could enforce the setting for each user one by one.
Would that be easier to implement?

@tomposmiko commented on GitHub (Apr 17, 2020): It would already be enough if we could enforce the setting for each user one by one. Would that be easier to implement?

GiteaMirror commented

@MOZGIII commented on GitHub (Jul 16, 2020):

Ok if we're gonna do this we need to think about what happens if a user tries to login without two factor.

Is it that they get redirected immediately to the enroll 2fa page similar to the must change password screen?

That would be reasonable.
It is also a good idea to allow specifying a time duration since registration until the 2FA requirement starts blocking the access. I.e. you can do some limited things until this 2FA enforcement timeout without 2FA.

@MOZGIII commented on GitHub (Jul 16, 2020): > Ok if we're gonna do this we need to think about what happens if a user tries to login without two factor. > > Is it that they get redirected immediately to the enroll 2fa page similar to the must change password screen? That would be reasonable. It is also a good idea to allow specifying a time duration since registration until the 2FA requirement starts blocking the access. I.e. you can do some limited things until this 2FA enforcement timeout without 2FA.

GiteaMirror commented

@njsubedi commented on GitHub (Dec 29, 2020):

Ok if we're gonna do this we need to think about what happens if a user tries to login without two factor.
Is it that they get redirected immediately to the enroll 2fa page similar to the must change password screen?

@zeripath I think the best way is to redirect to the 2FA Settings page, and show a message "Your administrator has made 2FA mandatory for all users who use $AUTHENTICATION_SOURCE authentication."

@njsubedi commented on GitHub (Dec 29, 2020): > Ok if we're gonna do this we need to think about what happens if a user tries to login without two factor. > Is it that they get redirected immediately to the enroll 2fa page similar to the must change password screen? @zeripath I think the best way is to redirect to the 2FA Settings page, and show a message "Your administrator has made 2FA mandatory for all users who use $AUTHENTICATION_SOURCE authentication."

GiteaMirror commented

@andreas-bulling commented on GitHub (Oct 30, 2022):

Any updates on this? This feature would also be super important for me. Thanks!

@andreas-bulling commented on GitHub (Oct 30, 2022): Any updates on this? This feature would also be super important for me. Thanks!

GiteaMirror commented

@lunny commented on GitHub (Oct 30, 2022):

#16880 try to fix this but closed.

@lunny commented on GitHub (Oct 30, 2022): #16880 try to fix this but closed.

GiteaMirror commented

See https://github.com/go-gitea/gitea/issues/13606#issuecomment-947320267

@wxiaoguang commented on GitHub (Oct 30, 2022):

That's an impossible task at the moment.

But if you are using Gitea for private usage, you can take the PR https://github.com/go-gitea/gitea/pull/16880 (build your own Gitea) , it works well for that case. I am keeping sync my 2FA branch with main branch.

I closed https://github.com/go-gitea/gitea/pull/16880 to reduce invalid pending PRs and avoid unnecessary CI resource consumption.

@wxiaoguang commented on GitHub (Oct 30, 2022): That's an impossible task at the moment. See https://github.com/go-gitea/gitea/issues/13606#issuecomment-947320267 But if you are using Gitea for private usage, you can take the PR https://github.com/go-gitea/gitea/pull/16880 (build your own Gitea) , it works well for that case. I am keeping sync my 2FA branch with main branch. I closed https://github.com/go-gitea/gitea/pull/16880 to reduce invalid pending PRs and avoid unnecessary CI resource consumption.

GiteaMirror commented

@OdinVex commented on GitHub (Jan 13, 2023):

Would like the ability to easily specify the algorithm, digit count, and period across the server.

@OdinVex commented on GitHub (Jan 13, 2023): Would like the ability to easily specify the algorithm, digit count, and period across the server.

GiteaMirror commented

@Mikaela commented on GitHub (Feb 22, 2023):

Shouldn't this have been implemented before https://github.com/go-gitea/gitea/pull/22999 and https://github.com/go-gitea/gitea/pull/23023?

If the organisation requires 2FA, then everyone has it enabled and there is no question about it.

@Mikaela commented on GitHub (Feb 22, 2023): Shouldn't this have been implemented before https://github.com/go-gitea/gitea/pull/22999 and https://github.com/go-gitea/gitea/pull/23023? If the organisation requires 2FA, then everyone has it enabled and there is no question about it.

GiteaMirror commented

@lunny commented on GitHub (Feb 22, 2023):

Shouldn't this have been implemented before #22999 and #23023?

If the organisation requires 2FA, then everyone has it enabled and there is no question about it.

Users could enable 2FA in their settings, but no option for the organization/team to enforce that.

@lunny commented on GitHub (Feb 22, 2023): > Shouldn't this have been implemented before #22999 and #23023? > > If the organisation requires 2FA, then everyone has it enabled and there is no question about it. Users could enable 2FA in their settings, but no option for the organization/team to enforce that.

GiteaMirror commented

@brechtvl commented on GitHub (Feb 23, 2023):

For organizations, I think it would be better to make the member somehow inactive until they enable 2FA. And then users can add 2FA or remove themselves from the organization when they want to.

Organizations shouldn't have the power to disrupt a user's login in my opinion. Also for API application access, one organization adding an 2FA requirement should not block access entirely, so you would need a concept of inactive membership in only some organizations anyway.

Or just removing the member of course, it's just a bit less convenient. Then the member can not fix the problem themselves but rather has to ask the owner to add them again.

@brechtvl commented on GitHub (Feb 23, 2023): For organizations, I think it would be better to make the member somehow inactive until they enable 2FA. And then users can add 2FA or remove themselves from the organization when they want to. Organizations shouldn't have the power to disrupt a user's login in my opinion. Also for API application access, one organization adding an 2FA requirement should not block access entirely, so you would need a concept of inactive membership in only some organizations anyway. Or just removing the member of course, it's just a bit less convenient. Then the member can not fix the problem themselves but rather has to ask the owner to add them again.

GiteaMirror commented

@ruess commented on GitHub (May 22, 2023):

For organizations, I think it would be better to make the member somehow inactive until they enable 2FA. And then users can add 2FA or remove themselves from the organization when they want to.

To me this is a logical and easy way to implement this. We don't have to mess with the current login system, but can simply restrict the user's capabilities until they enable 2FA.

@ruess commented on GitHub (May 22, 2023): > For organizations, I think it would be better to make the member somehow inactive until they enable 2FA. And then users can add 2FA or remove themselves from the organization when they want to. To me this is a logical and easy way to implement this. We don't have to mess with the current login system, but can simply restrict the user's capabilities until they enable 2FA.

GiteaMirror commented

@OdinVex commented on GitHub (May 22, 2023):

I think it might be good to hide the fact that 2FA isn't enabled for a user from other entities, so that Organizations can't probe accounts to figure out if they have 2FA (at least until they become a member with 2FA?)? Rogue Organizations, I'm thinking.

@OdinVex commented on GitHub (May 22, 2023): I think it might be good to hide the fact that 2FA isn't enabled for a user from other entities, so that Organizations can't probe accounts to figure out if they have 2FA (at least until they become a member with 2FA?)? Rogue Organizations, I'm thinking.

GiteaMirror commented

@csteaderman commented on GitHub (Aug 25, 2023):

Any status/progress on this issue?

@csteaderman commented on GitHub (Aug 25, 2023): Any status/progress on this issue?

GiteaMirror commented

@wxiaoguang commented on GitHub (Aug 25, 2023):

No, but you could build your own binary by my patch #16880 (there are design details) / https://github.com/wxiaoguang/gitea/tree/enforce-2fa

@wxiaoguang commented on GitHub (Aug 25, 2023): No, but you could build your own binary by my patch #16880 (there are design details) / https://github.com/wxiaoguang/gitea/tree/enforce-2fa

GiteaMirror commented

@csteaderman commented on GitHub (Aug 25, 2023):

No but you could build your own binary by my patch #16880 https://github.com/wxiaoguang/gitea/tree/enforce-2fa

Does your patch enforce site wide 2FA, or is it per-organization? Is there a PR to merge this into the main source?

@csteaderman commented on GitHub (Aug 25, 2023): > No but you could build your own binary by my patch #16880 https://github.com/wxiaoguang/gitea/tree/enforce-2fa Does your patch enforce site wide 2FA, or is it per-organization? Is there a PR to merge this into the main source?

GiteaMirror commented

@rudolphfroger commented on GitHub (Mar 9, 2024):

Apparently this feature is now advertised as a Gitea Enterprise edition advantage, so I assume this feature won't happen in the open source edition?

@rudolphfroger commented on GitHub (Mar 9, 2024): Apparently this feature is now advertised as a Gitea Enterprise edition advantage, so I assume this feature won't happen in the open source edition?

GiteaMirror commented

@prologic commented on GitHub (Mar 9, 2024):

Why would this be an Enterprise-only feature?

@prologic commented on GitHub (Mar 9, 2024): Why would this be an Enterprise-only feature?

GiteaMirror commented

@rudolphfroger commented on GitHub (Mar 9, 2024):

Sorry, I didn't include a reference: https://blog.gitea.com/gitea-enterprise/

@rudolphfroger commented on GitHub (Mar 9, 2024): Sorry, I didn't include a reference: https://blog.gitea.com/gitea-enterprise/

GiteaMirror commented

@techknowlogick commented on GitHub (Mar 12, 2024):

It will certainly be added to the project, or at the very least, I hope it will be, as any contribution needs to follow the contribution guidelines and the process outlined in the document. The status of the code in the commercial offering from CommitGo, is that it was developed for a customer, and we are working with them to ensure that the code can and does meet the DCO that Gitea requires of any contribution. I believe the PR linked above can still be applied to a Gitea build, and will meet your needs. From the comments on it, a different approach and changes elsewhere in the system may be the path forward that the project will take, as a proposal for a working group to discuss was suggested.

@techknowlogick commented on GitHub (Mar 12, 2024): It will certainly be added to the project, or at the very least, I hope it will be, as any contribution needs to follow the contribution guidelines and the process outlined in the document. The status of the code in the commercial offering from CommitGo, is that it was developed for a customer, and we are working with them to ensure that the code can and does meet the DCO that Gitea requires of any contribution. I believe the PR linked above can still be applied to a Gitea build, and will meet your needs. From the comments on it, a different approach and changes elsewhere in the system may be the path forward that the project will take, as a proposal for a working group to discuss was suggested.

GiteaMirror commented

@prologic commented on GitHub (Mar 13, 2024):

Good to hear 👌 I may have to increase my monthly donations 😅

@prologic commented on GitHub (Mar 13, 2024): Good to hear 👌 I may have to increase my monthly donations 😅

GiteaMirror commented

@11Firefox11 commented on GitHub (Sep 10, 2024):

Are there any news on this?

@rudolphfroger even better reference: https://docs.gitea.com/enterprise/features/mandatory-2fa .

@11Firefox11 commented on GitHub (Sep 10, 2024): Are there any news on this? @rudolphfroger even better reference: https://docs.gitea.com/enterprise/features/mandatory-2fa .

GiteaMirror commented

@warasilapm commented on GitHub (Sep 11, 2024):

+1

This is a feature we'd all like to see outside of Enterprise.

@warasilapm commented on GitHub (Sep 11, 2024): +1 This is a feature we'd all like to see outside of Enterprise.

GiteaMirror commented

@ggarret314 commented on GitHub (Dec 18, 2024):

My work wanted this as a feature. I took what @wxiaoguang made in #16880 and updated it for the most recently released version of Gitea (v1.22.6), plus and minus a few changes. I have it in a branch in my own repo here: https://github.com/ggarret314/gitea/tree/v1.22.6-enforce2fa

I see the comments made in #13606(comment), but I still don't understand how this can be a requested feature with such a simple goal for as long as it has been without any implementation. If I have more time to learn Gitea's codebase and the PR process, I'll try to re-up this issue. Until then, I'll try to take the guidon from wxiaoguang and update current versions of Gitea with enforced 2fa ability.

@ggarret314 commented on GitHub (Dec 18, 2024): My work wanted this as a feature. I took what @wxiaoguang made in [#16880](https://github.com/go-gitea/gitea/pull/16880) and updated it for the most recently released version of Gitea (v1.22.6), plus and minus a few changes. I have it in a branch in my own repo here: https://github.com/ggarret314/gitea/tree/v1.22.6-enforce2fa I see the comments made in [#13606(comment)](https://github.com/go-gitea/gitea/issues/13606#issuecomment-947320267), but I still don't understand how this can be a requested feature with such a simple goal for as long as it has been without any implementation. If I have more time to learn Gitea's codebase and the PR process, I'll try to re-up this issue. Until then, I'll try to take the guidon from wxiaoguang and update current versions of Gitea with enforced 2fa ability.

GiteaMirror commented

@eeyrjmr commented on GitHub (Dec 18, 2024):

I see the comments made in #13606(comment), but I still don't understand how this can be a requested feature with such a simple goal for as long as it has been without any implementation.

why so long? well it takes someone to implement it. There is limited coders and even fewer reviewers and also different people have different opinions on what is important... an infinite number of people stating an infinite number of features is the most important means that it won't get done

Luckily this feature has been implemented and is included within 1.23 (release candidate). if you cross to the bottom of the issue you linked #13606 you will see @wxiaoguang committed to it and implemented it in https://github.com/go-gitea/gitea/pull/32687

@eeyrjmr commented on GitHub (Dec 18, 2024): > I see the comments made in [#13606(comment)](https://github.com/go-gitea/gitea/issues/13606#issuecomment-947320267), but I still don't understand how this can be a requested feature with such a simple goal for as long as it has been without any implementation. why so long? well it takes someone to implement it. There is limited coders and even fewer reviewers and also different people have different opinions on what is important... an infinite number of people stating an infinite number of features is the most important means that it won't get done Luckily this feature has been implemented and is included within 1.23 (release candidate). if you cross to the bottom of the issue you linked #13606 you will see @wxiaoguang committed to it and implemented it in https://github.com/go-gitea/gitea/pull/32687

GiteaMirror commented

@ggarret314 commented on GitHub (Dec 18, 2024):

Luckily this feature has been implemented and is included within 1.23 (release candidate). if you cross to the bottom of the issue you linked #13606 you will see @wxiaoguang committed to it and implemented it in #32687

I looked through the commits, the problem being resolved there is separate from what I'm solving in my fork (as well as what @wxiaoguang was solving in his #16880 changes). I'm not trying to stop password-based login, I just want 2FA enforced, which is what the open issue this comment thread is about. My solution doesn't solve exactly what the initial commenter wants with separate settings for global / organizational enforcement, but it does enforce 2FA to be enabled globally across the site, using the 2FA solution provided inside Gitea. My apologies if it was confusing why I cross referenced a different issue; I referenced his comment because he mentioned it on why enforcing 2FA (this issue) is hard to implement.

@ggarret314 commented on GitHub (Dec 18, 2024): > Luckily this feature has been implemented and is included within 1.23 (release candidate). if you cross to the bottom of the issue you linked #13606 you will see @wxiaoguang committed to it and implemented it in #32687 I looked through the commits, the problem being resolved there is separate from what I'm solving in my fork (as well as what @wxiaoguang was solving in his #16880 changes). I'm not trying to stop password-based login, I just want 2FA enforced, which is what the open issue this comment thread is about. My solution doesn't solve exactly what the initial commenter wants with separate settings for global / organizational enforcement, but it does enforce 2FA to be enabled globally across the site, using the 2FA solution provided inside Gitea. My apologies if it was confusing why I cross referenced a different issue; I referenced his comment because he mentioned it on why enforcing 2FA (this issue) is hard to implement.

GiteaMirror commented

@wxiaoguang commented on GitHub (Dec 19, 2024):

I didn't continue " (Discontinued) Enforce two-factor authentication #16880 " because it is far from ideal to be integrated into Gitea (I am still using it in my private instance). Ideally it should be an org-level config option and it should also work with different auth-source.

@wxiaoguang commented on GitHub (Dec 19, 2024): I didn't continue " (Discontinued) Enforce two-factor authentication #16880 " because it is far from ideal to be integrated into Gitea (I am still using it in my private instance). Ideally it should be an org-level config option and it should also work with different auth-source.

GiteaMirror commented