Why does Nix/Nixpkgs/NixOS GitHub organization require all members to have two-factor authentication enabled?

I have been invited to join the Nix/Nixpkgs/NixOS GitHub organization after a contribution to a repository. FYI, I use a different pseudo on GitHub.

If I do not have a mobile phone, I have no intention to get one. If I do have a mobile phone, I have no intention to let GitHub know about it. I guess you see my point, I want to stay as anonymous as I can.

I believe the fact that I have a phone or not should not hinder my ability to contribute to this great community.

I did not fully understand yet what being a member of the Nix/Nixpkgs/NixOS GitHub organization would allow me to do. But, why does Nix/Nixpkgs/NixOS GitHub organization require all members to have two-factor authentication enabled?

1 Like

You have two options regarding GitHub 2FA:

  • SMS based
  • time-based one-time password (TOTP) based

While the SMS option requires a phone number, you should be able to set up TOTP based 2FA even without a phone.

6 Likes

In general using 2FA or passwordless authentication will become more and more the default and some services require it for the additional security.

The place I am working at requires 2FA (or 3FA even) for a lot of internal services.

  • Username and password
  • TOTP
  • Accessing from an authorized host (only for a handful of services that deal with very sensible data)
2 Likes

I am glad to read that. I will investigate this solution.

You may be interested e.g. in GitHub - pcarrier/gauth: Google Authenticator in your terminal.

It’s a bit of a myth that TOTP auth only works on phones, because service providers insist on making you use their client implementation (i.e., Google authenticator, Microsoft authenticator, 
), and don’t advertise the fact that they’re compatible with one another. Some actually do not implement the spec, and require use of their phone apps (Steam, Amazon), but this is less common for services that target more tech-savvy end users.

It’s a bit sad - this gives it a bad rep (nobody likes being “forced” to install Google apps), even though TOTP is just a nice client-certificate based authentication scheme. I’d personally prefer using it over password auth instead of being relegated to “second factor” status.

Requiring 2FA is a good thing, because it means people’s accounts are less likely to be taken over and used to publish malware to nixpkgs.

4 Likes

You can still contribute a lot even without being in any (NixOS GitHub) organization.

4 Likes

Why?

  • Because it’s 2022 and this should be standard / expected now.
  • Because lots of people depend on the integrity of the code, and that in turn depends on the integrity of the accounts who can commit to the code

etc, etc. It’s not really what you were asking, but it’s worth being clear why.

There are lots of ways to do 2FA without a mobile / SMS. That’s probably the least-preferable option anyway, from both a security standpoint and because of the objections you outlined.

Others have noted that you can use a TOTP generator application. You can also use a FIDO2 security key: Yubikey is the well-known brand, there are others including a number of high-quality open-source designs.

4 Likes

I use oathtool as a flexible command-line too for working with TOTP. For example it even tolerates my «intentionally-off» time etc.

Many password managers actually support TOTP in addition to plain passwords.

On Android (even AOSP with no Google Apps and no cellular connection) there is, say, FreeOTP+ (available in F-Droid)

2 Likes

While the usability aspect of it is obvious, storing OTP seeds on the same device you’re typing your passwords on is pretty poor from a security point of view.

In my opinion it cannot be considered 2FA if a compromise of a single device (i.e. your laptop/desktop) allows an attacker to authenticate without the actual account holder’s involvement.

Using a TOTP app on a different device or a hardware key which cannot leak OTP seeds should be the bare minimum.

2 Likes

I disagree, as it’s irrelevant whether my phone or laptop is the device that compromises all, as both are regularly used to log in with passwords and my laptop is generally physically and virtually safer than my phone.

If you want to argue that point, you need a dedicated authentication device that’s never used for anything else (and definitely not a phone). Ideally I’d have a hardware token generator hooked up to TOTP instead, but my yubikey doesn’t support that, so this is the interim until I upgrade one day.

Though that also quickly becomes a single factor if you use a password manager :wink:

1 Like
  1. Level of compromise allowing exfiltrating the keys from password manager (presumably encrypted on disk) is not really different from being able to steal browser session and use it on the same device to grant yourself a full-power set of tokens, for instance.

  2. I have read GitHub’s 2FA instructions. They recomend putting account recovery keys into a password manager anyway. The requirement has been discussed, it is 2FA as GitHub defines it, and yes, effectively password manager use enforcement, that’s indeed the plan.

Right, if you’re using said device to login to GitHub then you should probably consider using a hardware token instead. I should’ve worded it differently to cover such use.

I do think in general you should consider phones to be more secure. My laptop happily runs arbitrary applications, whereas Google/Apple won’t let me (double edged sword, though).

Interesting.

Suppose it makes sense from GitHub’s perspective (to combat password reuse), but if you’re already using unique passwords it doesn’t really have any added security benefit.

I know about publication bias, but when people intentionally look for malware in App Store / Google Play, they often find it, and often under names intended to be confused to reasonably popular apps.

And in case of Android, what is actual available for many devices is quite a bit behind on kernel patches. Which is actually good because it increases chances of rooting. On the bright side, on Android you can install F-Droid where source-built-by-F-Droid requirement serves as at least a bit of a deterrent.

(I actually use rooted Android and a full Linux chroot, because why would I not want to have a useful CLI environment available)

Effectively, enforcing password manager is as good a 2FA as you can get for mass users, because it requires access to a device bearing the key database, and knowledge of master password to unlock it. Sure, it has risks (but also benefits, such as ability to have a meaningful backup strategy), but the main risk vector is a browser takeover anyway


1 Like

@koolean, as others have pointed out a FIDO2 hardware key like YubiKey is a convenient solution. Another option I’ve used before for services that don’t accept a hardware key as a 2FA method is the package go-2fa available in nixpkgs which provides a minimal cli interface. It’s pretty simple to use it to generate one time passcodes for 2FA purposes.

Maybe, however note that there is a serious inclusivity issue here; hardware tokens are far from free of cost. I think suggesting that one can only contribute to nixpkgs safely if one owns such a token is a bit tone deaf when a contributor is complaining about their lack of phone meaning they cannot contribute.

Also consider the threat model here; the point of 2FA is to require both factors for a login. Assuming you don’t store your passwords as plain text on the device you use to sign in, these are obviously still two factors - a knowledge factor (your encryption password) and an ownership factor (the device used to store your TOTP key).

This is weakened by malware being able to exploit a single device, and hence extracting your knowledge and ownership factor via keyloggers, but as @7c6f434c says, once you have that level of access to a device you also have access to browser session storage and therefore free-reign over account access anyway, so your suggested approach doesn’t add additional protection here.

Having a third device is great, but I don’t think it offers any direct protection against a threat that using TOTP on an end user device doesn’t, specifically for systems that use session cookies such as GitHub.

For other systems hardware tokens are an obvious plus (e.g., client certificates for SSH access), and they are more resistant to malware, but under reasonable assumptions for web access TOTP on a laptop should perform similarly against a dedicated attack, and completely stop password phishing and such.

This is false. My phone also happily runs arbitrary applications, at least to the extent my computers do. Honestly it’s easier there than on NixOS, I need to write a whole package almost every time I want to “just run something”. On my phone I just need to tick a box saying “allow apps from this location”.

Besides that, claiming Apple or Google vet applications makes their platform safe is definitely a fallacy. The mobile app stores have been known to distribute malware, in many wondrous ways, from taken-over ad delivery networks injecting malware (and executing it because clearly they’re designed for maximum security, not profit) to simply missed viruses in submitted binaries built on malware-ridden eclipse instances. This isn’t an uncommon thing on rarely used apps either, Wechat and Twitter at least have both been compromised in the past, and are well among the most used.

Neither is perfect, of course, I rely on open source contributors and software that I also can’t perfectly track, all of which could try to do evil, so arguably it’s inherently broken. Nixpkgs is at least more strict about the build processes than either of Google or Apple, but ultimately trust is a difficult topic.

Personally, I trust this particular instance of the software delivery mess a bit more, especially because my computers have declarative, reproducible configurations that I can manage - I feel that I can know my attack surface here. Not on my phone.

1 Like

Perhaps it’s my fault for derailing the discussion from the original issue, but by no means I meant to suggest this should be a requirement for nixpkgs (where membership of the GitHub organization doesn’t even imply commit access) or OP.

Protecting against password spraying attacks using ‘GitHub 2FA’ is by all means reasonable for nixpkgs. It’s just that I personally think one should raise the bar to be able to say you’re truly using 2FA.

That feature is non-existent on iOS and somewhat hidden on Android (for good measure). Even if I would install your rogue application, you’d be unable to steal my authenticator seeds. It’s not just about app store vetting (which is in some way similar to NixOS as you’ve remarked).

Alternatively, consider ransomware: no credible threat on mobile, huge problem on PC. That’s why I consider mobile to be more secure in general.

Can’t argue with that from an ideological point of view, but as far as my own devices are concerned I think Google might just be doing a better job at keeping my phone/email secure than I trust myself at using my own laptop.

In any case, I’ll let it be from here since I did not intend to start a 2FA meta discussion. Luckily it looks like OP got all the answers they need prior to my derailment :slight_smile:

2 Likes

If you need Trueℱ 2FA, you should drop vague terms (as we all know by now, the worst 2FA implementations might make either factor sufficient to do account «recovery» — or hijacking), and speak about specific requirements in specific threat models. GitHub 2FA is fortunately a thing that does not move too fast.

Me, a user of rooting apps: Well, it’s complicated

Because ransomware pays off best when hitting enterprise data from time to time, and for an below-average-digitalness enterprise smartphones are just toys?

For personal nstall-and-passively-receive-data spying, smartphones are frequent targets.

That assumes using only Google Pixel phones, right? Because once it is Google and phone vendor, I have a ton of doubts already.

(Personally, I have doubts in having use for unrooted Android, but that’s another question)

Also, for wide low-effort attacks being imperfectly compatible is often as useful as excellence. The exploits against iOS cost a lot on black market bcause they are both hard and widely applicable.

Correct, that’s why I referred to myself only. It certainly wouldn’t hold for most other vendors.