-
-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Require 2FA #91
Comments
This comment has been minimized.
This comment has been minimized.
I would support this requirement. We've had a related discussion in python-commiters: https://mail.python.org/archives/list/[email protected]/message/IS5ZGCRBBZ2RRRBJO4ZPG6P6XDPSDEYI/ |
https://arstechnica.com/gadgets/2021/03/hackers-backdoor-php-source-code-after-breaching-internal-git-server/ seems to cover it too. Googling "php github hack" shows a number of articles. Summary: Attackers got into PHP's custom git server and inserted a backdoor; PHP moved their repo to GitHub and required 2FA in response. |
This also came up in discussion among the PEP Editors; enforcing this would substantially reduce the risk of compromise and lower the security tradeoff of allowing more people potentially useful permissions. |
In any case, I've reduced the repo access of the team to Maintainer, and made Brett, Barry and myself Admins. Where are the controls to require 2FA? It would not be a bad idea to require this for all python org members. |
Here: Note the warnings, first of all:
|
Yeah; if the SC does decide to go ahead with this, I'd suggest giving all org members plenty of warning first and a reasonable amount of time (a month?) to transition before executing. Since GitHub disabled username/password authentication and has required tokens for app access as of some time ago, this shouldn't break apps, bots or integrations, or circumstances other than interactive login—I think, anyway. |
See also https://discuss.python.org/t/remove-coordinator-role-of-inactive-coordinators-on-bugs-python-org/866 about bugs.python.org that I reported in 2019 and remains an issue in 2022. |
IMO the attack scenario is to introduce malicious code in the Python source code. An attacker steals credentials (login/password) of a core dev who doesn't use 2FA, they can create a PR and merge it. 2FA doesn't cover all cases, but it reduces the risk of such attack. Keys are Yubikeys are cheap. The PSF may cover the cost for core devs. But it's also possible to use free applications like Google Authenticator or FreeOTP on a phone. |
Twilio's Authy is another good cross platform choice for MFA 2FA app. |
I've added this to our agenda. |
Has there been any movement on this front lately? Seems like this continues to be a serious vulnerability in light of the increase in supply chain attacks and deteriorating global geopolitical situation... |
Still being looked into. GitHub is ultimately going to be requiring it for everyone anyways... Our goal is to see infrastructure issues that it would break identified sooner than GitHubs global change so we can flip 2FA on sooner. It's and org-wide setting so every repo under /python/ has to be ready at once. I believe we're mostly waiting on some infrastructure work right now. |
Sounds like this is now happening: python/core-workflow#489 |
Our understanding is that this is complete now that GH forced the change on the world and @ambv helped get the bots fixed. :) reopen specific issues if 2FA bot hiccups and whatnot come up. |
From what I can determine, there is still benefit to enabling the org setting after the GitHub change, which also greatly reduces the downsides of enabling it. The GitHub requirement means that everyone whom GitHub records as having contributed code to a public repo will be required to enable 2FA, which should be nearly everyone in the org (though there might be a few special cases, particularly among core devs who haven't been active committing since the GitHub transition, or folks who are members for other reasons than code contributions). However, the GitHub change has no immediate security benefit for accounts of core devs and other org members who haven't been active on GitHub since the requirement was introduced; any untrusted party who obtains their password can log in at any time and simply enable 2FA locked to their device, and immediate have full permissions on the Python org. These accounts (missing 2FA, having old, possibly outdated passwords; are no longer regularly monitored; and possibly lacking other up to date notification, security and recovery measures) are the most vulnerable to compromise and have the smallest potential negative impact to remove. By contrast, requiring 2FA via the org setting prevents any compromise of such inactive accounts (or any other special cases that slipped through the cracks) from in turn compromising the Python org and repositories within, as users without 2FA enabled are removed from the organization; they are notified and are automatically reinstated if they enable 2FA within 3 months, but after that time they must contact an org owner via secure core dev channels and be added back manually, presumably after due diligence review. Furthermore, the downsides of enabling the setting now are greatly reduced from the prior situation, as all bots and services that are still in use have already been converted, and only CPython org members who haven't been active in the past ≈year or more who are still missing 2FA would be removed, and they would be notified and automatically reinstated if they enabled 2FA within a further 3 months; otherwise, they could be reinstated at any time by an org owner after manual review. Therefore, now seems as good a time as ever to enable this setting and close this security hole properly, as well as automatically inactivate core dev permissions that aren't being used per the principle of least privilege. |
@ewdurbin, if you OK this change on an organizational level, I can make it. |
At this point I see no reason not too! |
I will do so after documenting what access the 13 users that would be booted currently have. |
No specific access was noted, but the following outside collaborators were removed as a result of enforcing 2FA at the org level: @sofide sofide Sofía Denner If any of those folks require restoration of access, please respond here! |
FYI turned on 2FA and re-added @python-docs-turkish (our hardworking translation bot). |
Hi, I enabled 2FA, please restore my access. Thank you~ |
Hi, I've activated the 2factor authentication, can I get my access restored? I've not contributed in a while to the python-doc-es project but would want to keep doing in the future. Best wishes. |
Hi, I've also activated 2FA and I'd like to get my access restored. I also look forward to contributing more in the future! |
Ah, sorry, it'd seemed to me from reading the GitHub docs that the reinstatement would be automatic if done within three months of enabling the setting, but rechecking the docs now it seems it still requires an owner approval step (but your previous roles, team memberships, permissions, assignments, subscriptions, settings, etc will then be automatically reinstated without additional action). Sorry if there was any misunderstanding there, and glad to see you all back! |
@CAM-Gerlach in this instance that re-instantiation doesn't work as all of the impacted users were outside collaborators. |
@clacri, your status has been restored for the python-doc-es repository. |
hi @sefikaozturk i'm sorry but i did not record what repository you were marked as an outside collaborator on, can you recall? |
hi @mindihx i'm sorry but i did not record what repository you were marked as an outside collaborator on, can you recall? |
Hi @ewdurbin, I have activated the 2FA and I'd like to get my access restored. |
In case I don't get re-elected, I wanted to suggest we require 2FA for committers. The overhead is minimal if you regularly use the same machine and the safety guarantees are worth any potential cost in my opinion. We can also probably get committers a 2FA hardware device if they want one.
And people hacking programming languages is not unheard of.
The text was updated successfully, but these errors were encountered: