Ability to enforce two-factor authentication

[minecrafter]

Currently, two-factor authentication is optional. It would be nice if we had a global (site) or per-organization setting to enforce two-factor authentication.

• Global: If you log in and do not have two-factor authentication, you will be forced to enroll when you log in.
• Organization: You can not join an organization until you enable two-factor authentication. Existing members without two-factor authentication will be forced to turn it on (GitHub removes users from the organization).

[bkcsoft]

As for per-organization change, I propose that if you login w/o 2FA enabled you're account will be redirected to /user/settings/two_factor with an option to leave the "offending" organization :)

Obviously the 2FA-page would need an update to list orgs (that require 2FA) to leave if you disable 2FA.

[elvarb]

This feature is very important for overall security.

Best way to implement it would be to have it a part of Authenticators settings, that way you can for example require 2fa for ldap imported users while having it optional for local users.

[yarumair]

Just wondering if this is implemented as i think its pretty nice feature to have within an organization

[stale]

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.

[9thWonderAgency]

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

[zeripath]

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?

[tomposmiko]

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

[MOZGIII]

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.

[njsubedi]

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."

[andreas-bulling]

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

[lunny]

#16880 try to fix this but closed.

[wxiaoguang]

That's an impossible task at the moment.

See #13606 (comment)

But if you are using Gitea for private usage, you can take the PR #16880 (build your own Gitea) , it works well for that case. I am keeping sync my 2FA branch with main branch.

I closed #16880 to reduce invalid pending PRs and avoid unnecessary CI resource consumption.

[OdinVex]

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

[Mikaela]

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.

[lunny]

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.

[brechtvl]

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.

[ruess]

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.

[OdinVex]

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.

[csteaderman]

Any status/progress on this issue?

[wxiaoguang]

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

[csteaderman]

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?

[rudolphfroger]

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?

[prologic]

Why would this be an Enterprise-only feature?

[rudolphfroger]

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

[techknowlogick]

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.

[prologic]

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