Many organizations are moving to 2FA/MFA [LWN.net]

Many organizations are moving to 2FA/MFA

Posted Jul 13, 2022 22:56 UTC (Wed) by david.a.wheeler (subscriber, #72896)
Parent article: "Critical" projects and volunteer maintainers

Many organizations are encouraging or requiring that at least some OSS projects use 2FA/MFA tokens. I suspect that eventually 2FA/MFA tokens will simply be a requirement for all major forges (like GitHub) and for all major package repositories (like PyPI, npm, and RubyGems).

There's a reason this is happening. Unfortunately, attackers are increasingly focusing on taking over OSS developers' accounts - and they're succeeding. The attackers then change the project's source code and/or deployed packages, potentially resulting in a devastating impacts on OSS users. According to "Towards Measuring Supply Chain Attacks on Package Managers for Interpreted Languages" account compromise is the second most common supply chain attack (after typosquatting) on OSS packages for dynamic programming languages like JavaScript, Python, and Ruby. Attackers directly focus on account takeover. For example, eslint-scope, a package with millions of weekly downloads in npm, was compromised to steal credentials from developers.

The easy solution, one that counters these attacks in almost all cases, is requiring 2FA/MFA tokens. Nobody wants to add requirements. But users presume that the OSS is being being provided by the OSS developers, not by an attacker who broke into the OSS developer's account via a broken password or SIM swapping.

Here are some of the many organizations supporting OSS that are encouraging or requiring 2FA/MFA tokens (in some cases at least):

GitHub. GitHub will require all code contributors to use 2FA by the end of 2023
PyPI (Python). PyPI is giving away 2FA security tokens and will require 2FA for critical projects (which they define as their top 1% of downloads). My understanding is that they'll eventually require it for all projects.
RubyGems (Ruby). The maintainers of at least the top 100 RubyGems packages have started to see warnings on the RubyGems command-line tool and website if MFA is not enabled on their accounts.
npm (JavaScript). NPM is making 2FA mandatory to their first cohort, all maintainers of top-100 npm packages by dependents, with a wider roll out planned.
The Open Source Security Foundation (OpenSSF)'s "Great MFA Distribution Project". This project distributed free MFA tokens to a number of OSS projects in 2021 (those identified as critical).

Nobody is forcing anyone to use these forges and package repositories. I think it's reasonable for them to set some basic requirements as long as they have a good reason, aren't too hard to implement, and don't harshly impede other goals like privacy. I think this meets the bar.

to post comments

Many organizations are moving to 2FA/MFA

Posted Jul 14, 2022 9:37 UTC (Thu) by roc (subscriber, #30627) [Link] (5 responses)

These tokens are pretty cheap and pretty convenient to use. I'm glad Github etc are going to require them. I even have my Github account set up to require touching the token when pushing, and I got used to that pretty fast.

Many organizations are moving to 2FA/MFA

Posted Jul 14, 2022 11:34 UTC (Thu) by hmh (subscriber, #3838) [Link] (2 responses)

It is not even that selective / troublesome. Requires 2FA is not the same as requires a dedicated hardware token.

2FA apps running in a (hopefully separate) device are almost always accepted as well, at least for the forges.

So, your typical floss developer, even in areas where hardware tokens are either expensive or hard to acquire, can trivially get past that bar.

There really isn't any excuse for not mandating 2FA other than credential recovery procedures, as long as it is an interoperable one that is not going to cause any sort of vendor lock-in.

The recovery procedures are a indeed a concern, though.

Many organizations are moving to 2FA/MFA

Posted Jul 14, 2022 15:15 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

Of the practical options at scale, only FIDO (via WebAuthn in the case of the web, directly supported in your SSH client, or native APIs in smart phones) actually makes this attack (on user authentication) so difficult that adversaries will give up.

TOTP can be phished, it's maybe going to be a bit harder to phish the sort of person who writes a Python package than my mother, but on the other hand it's probably a spear phishing exercise and so the attacker is putting real work in not just spewing out a million bogus emails claiming to be from FedEx or whoever. This is why FIDO is so important that it's worth spending money (not very much money in the larger scheme of things, but spending money is annoyingly difficult in the sort of organisations that have money) to give people FIDO authenticators rather than just point them at TOTP. The "cheapest" viable attacks on FIDO appear to be: Persuade the user to give you their physical token e.g. call them and insist it needs replacing, send a "courier" to pick it up (this sounds like a good way to get arrested, Police may not understand Internet crimes, but they have seen this trick done with credit cards for decades). Persuade the user to install malware which can request suitable login credentials and send them to you, and then persuade the user to physically authorise that authentication. Both ideas are something you could imagine a state actor pulling off but aren't very practical for small time crooks, bored teenagers and suchlike real world attackers.

The difficult-to-acquire thing is probably given a misleading impression by the fact these tend to be US projects. Americans have a much easier time sending physical objects to a handful of countries and those are listed. But I assure you that a hacker living in Moscow right now, regardless of how they feel about their country's invasion of Ukraine, can get themselves a FIDO authenticator if they want one for example.

Many organizations are moving to 2FA/MFA

Posted Jul 14, 2022 19:34 UTC (Thu) by roc (subscriber, #30627) [Link]

Number porting attacks appear too easy for me to trust SMS code delivery. I've removed that option from my accounts wherever possible.

Many organizations are moving to 2FA/MFA

Posted Jul 15, 2022 19:21 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

> I'm glad Github etc are going to require them. I even have my Github account set up to require touching the token when pushing, and I got used to that pretty fast.

Is that something that you can set on your account or is it more that you only use `sk-` SSH keys?

If it is via token-anchored keys, how do you manage backup keys (I have…a few)? Do you just have N SSH keys registered or is there a way to make N keys unlock a single SSH keypair? (I really want to avoid "add new token's key" to every service if/when I get new ones because I prefer to manage a keypair per service as well and making that an NxM matrix sounds…horrendous[1].) I'm also worried about exhausting the key storage on the token (IIRC, an older method used up "slots" on the key, but docs about `sk-` keys don't mention hardware limits).

[1] You also end up with a O(n) configuration with `IdentitiesOnly` and leaks how many backups there are directly in the configuration.

Many organizations are moving to 2FA/MFA

Posted Jul 17, 2022 3:30 UTC (Sun) by alison (subscriber, #63752) [Link]

I once received email falsely purporting to be from github.com with embedded links that pointed to malware sites. That message arrived while I was interviewing for new positions, so having porn posted to my repos or having them deleted would have been awful. I wish that many more websites would support TFA, not least all online banking sites.