search

NixOS / nixpkgs

Nix Packages collection & NixOS
MIT License
18.39k stars 14.34k forks source link

Require 2FA for all committers #42761

Closed grahamc closed 6 years ago

grahamc commented 6 years ago

The Gentoo GitHub organization was hacked due to a password being leaked. We will be requiring 2FA on July 6. If your account does not have 2FA configured by that time, you will no longer have the ability to merge pull requests or push to the NixOS organization.

Once you have enabled 2FA please check the box next to your account.

If you miss the July 6 deadline, we can reinstate your access after you enable 2FA -- contact us.

Reference documentation:

Applications:

Hardware

If you have a FIDO / U2F token, you can use it with GitHub:

  hardware.u2f.enable = true;

and either use Google Chrome, or firefox-devedition-bin (firefox stable doesn't yet support u2f totally.) If you use firefox, visit about:config, search for security.webauth.u2f, and toggle it to true for it to work.

Accounts to go

Completed

Accounts to remove

grahamc commented 6 years ago

(Ping @vbgl @viric @vrthra who I couldn't ping in the issue description due to a 50 ping limit)

viric commented 6 years ago

I'm using FreeOTP+ in F-Droid. Fine.

7c6f434c commented 6 years ago

I chose One-TimePass from F-Droid. Also installed command-line oathToolkit.

Observation. Recovery codes that are recommended to save in password manager mean that the recommended setup is almost equivalent to random passwords in password manager, but probably also breaks phishing. So keeping it on the same device but not giving the browser UID access to the secret doesn't lose any security in realistic scenatios.

armijnhemel commented 6 years ago

I am trying to check the box next to my name as requested, but I can't. Anyway, I set up 2FA for my account.

7c6f434c commented 6 years ago

Well, it's not like GitHub has access to any technology that handles any merges, I guess it lost the lock race to my edit. I was indeed able to check your box.

7c6f434c commented 6 years ago

Hm. And the commit tokens are better than passwords (also random data stored in password manager and allowing commit access to all repos) because git doesn't literally send password to server as plaintext, and that's all?

7c6f434c commented 6 years ago

(speaking of new-user checklist and «contact us») and this use of first-person plural in «contact us» means that you are also now a person who can manage the member list?

grahamc commented 6 years ago

I can't manage the member list, but I know a guy :)

re commit tokens, I recommend using (encrypted) SSH keys of course.

All new users will be required to have 2FA enabled and after July 6 GitHub won't let us add new users who don't have 2FA enabled.

7c6f434c commented 6 years ago

SSH keys are not that different from tokens unless you consider algorithm attacks…

AndersonTorres commented 6 years ago

2FA updated here, ok!

oxij commented 6 years ago

I'm surprised there aren't many contrarian voices to this. Let me become one, as usual.

TL;DR

How do I get commit access without having a smartphone now?

GitHub's 2FA is a joke and I feel like, realistically, implementing this policy will only

Many words follow

The Gentoo GitHub organization was hacked due to a password being leaked.

1) I see two possibilities:

a) the password in question was reused, b) member's machine was hacked.

B) If member's machine gets hacked, you're f*cked just as much with this GitHub 2FA since, in all likeliness, recovery codes are going to be stored on the same device as the password. Hence the "2" part of 2FA is moot. GitHub's "2FA" is of the same level of security as "random passwords generated by GitHub".

A) If the password was reused you can gets the same level of security by asking all the members to either

2) What this policy change really does is it requires members of the organization to be handcuffed to a smartphone (with 98% probability of its OS being made by Google) or Chrome browser and Google Authenticator (100% probability being made by Google.)

Feels yuck to me to require non-free tools for developing a supposedly free OS, and to handcuff developers to Google.

3) If you really want to prevent Gentoo's incident in NixOS a much more realistic, secure (and just, and free) way to proceed is to take away all commit rights from everyone, require every change to go via a PR and either

I think both of these options are supported by GitHub right now too.

And, btw, you should start by getting land^W organization owner's account credentials into cold storage, not by requiring 2FA of peasants^W members.

4) Hypothetically (I'm not sure if GitHub can do this), you could also require everything to be merged via SSH, i.e. disable HTTP merge button.

I, for instance, use a simple bath script git fetch-github-pr <URL> that does exactly what is sounds like it does (and some more, like it can check if I already fetched that PR, name branches from titles, etc). Making it into a "merge button" by simplifying it into its bare bones and adding automatic merges seems pretty easy (made in a minute, not tested)

parsed=$(sed -n 's%^ *\(https://github.com/[^/]*/[^/]*\)/pull/\([^/.]*\)\([/.].*\)\? *$%\1\n\2%p' <<< "$1")
upstream=$(head -n 1 <<< "$parsed")
number=$(tail -n 1 <<< "$parsed")

git fetch nixpkgs
git checkout nixpkgs/master

branch="pull/$number"
git fetch "$upstream" +"pull/$number/head":"$branch"

git merge --no-ff -m "Merge pull request $upstream/$branch" $branch
git branch -d $branch
git push nixpkgs HEAD:master

In Firefox and derivatives you can then add a toolbar button that calls this script with the URL of the current page (see how org-mode does this http://orgmode.org/worg/org-contrib/org-protocol.html), i.e. exactly "toolbar merge button". Works across repos too, like you could merge PRs from Triton with this, if you wish :)

And that could be made actual 2FA: your SSH key and it's passphrase. Works with standard free tools like gpg, smart cards, and other hardware tokens like YubiKeys, doesn't handcuff you to Google.

Thanks for your attention.

andrew-d commented 6 years ago

How do I get commit access without having a smartphone now?

If you weren't aware, GitHub supports U2F - you can buy a fairly cheap one for about $9 on Amazon and use it without a smartphone. Firefox also supports U2F now, so you're not required to use Chrome.

Additionally, while I agree that requiring two-person sign-off is by far the better solution, using 2FA provides a non-negligible security benefit for the vast majority of committers who may reuse passwords, or that have malware that's not sophisticated enough to also exfiltrate 2FA seeds. It raises the bar to attack NixOS committers, so I personally am 👍 to the proposal.

oxij commented 6 years ago

How do I get commit access without having a smartphone now?

If you weren't aware, GitHub supports U2F

I saw that, the first sentence there is literally

After you configure 2FA via a TOTP mobile app or via SMS, you can add a security key that supports the FIDO U2F standard to use for two-factor authentication on GitHub.

and then in the HOWTO list

  1. You must have already configured 2FA via a TOTP mobile app or via SMS.

So, no.

7c6f434c commented 6 years ago

@oxij you have got a few of the technical requirements wrong. @andrew-d all is an order of magnitude simpler.

GitHub permits use of an open standard for generating 2FA codes, called TOTP — time-based one-time passwords. There are many free implementations.

As I have already mentioned, there are not only fully libre smartphone apps available in F-Droid (not requiring Google Play Services and working well on LineageOS) that support that standard, but also a free command-line tool packaged in Nixpkgs in oathToolkit. You might need a QR-code reader, but as the viewing conditions on a screenshot are perfect, anything — say zbar — will work well.

I have also commented on security model; yes, the difference with properly managed random passwords is very small (not precisely zero for 2FA secret in a password manager on the same device, though — cheap script-kiddie-level keyloggers catch passwords better), but I guess 2FA has the benefit of verifiability even if it works no better (everyone doing it rong in different ways is still better than someone doing password reuse from the point of view of being hit in stupid mass attacks).

andrew-d commented 6 years ago

I saw that, the first sentence there is literally

After you configure 2FA via a TOTP mobile app or via SMS, you can add a security key that supports the FIDO U2F standard to use for two-factor authentication on GitHub.

🤦‍♂️ welp, sorry about that - totally missed that line.

  1. You must have already configured 2FA via a TOTP mobile app or via SMS.

I can totally understand not wanting to use SMS 2FA (I don't either) 👍 I use FreeOTP on my phone and am pretty happy with it. And like @7c6f434c mentions, there's a bunch of command-line options.

Also worth mentioning: GitHub asks you to re-2FA fairly infrequently; I think I get asked about once a month or so.

samueldr commented 6 years ago

You might need a QR-code reader

It isn't necessary, as github can also provide the alternate text-based methods to seed the TOTP.

7c6f434c commented 6 years ago

@samueldr Thanks. Maybe it is my bias that I expect 2D code readers to make more sense than GitHub.

oxij commented 6 years ago

@7c6f434c

As I have already mentioned, there are not only fully libre smartphone apps available in F-Droid (not requiring Google Play Services and working well on LineageOS)

I implore you to show me a reasonably secure (either with no radio, or with free firmware for radio modules) device that can run LineageOS.

oathToolkit

Wait, so you're saying that I can use oathToolkit + zbar in place of a smartphone?

I assumed it required some specialized hardware, like those proprietary smartcards smartphone have builtin (SIM-card is one of those, replaceable, most have others non-replaceable ones, e.g. for Google/Apple Pay, hiding data they collect about you away from you, etc, Macs have "memory chips of unknown purpose" on their motherboards too, btw).

But if I can just run oauthToolkit + zbar to emulate 2FA on my laptop, then

So, right now with GitHub I mostly use ssh with proper 2FA, when using HTTP interface I copy-paste my random password from pass that lives in a different VM from the browser.

After this change (if I would ever get commit access to NixOS) when using HTTP interface I would need to first copy-paste my password from pass as usual, run zbar, copy-paste the result to dom0, feed result to oauthToolkit and then copy-paste the output of that into the browser VM again.

Seems like 0.33x the efficiency with 0 more security to me.

vcunat commented 6 years ago

The point is to have at least some second factor. Most phones surely aren't terribly hard to compromise as well, but two different factors are just harder than one. If you want even better security cheaply, I suppose you'd go for a U2F token. AFAIK the second factor is only used once a very long time on each device, so it should normally be not much extra hassle. It has worked well for me for a long time and on multiple providers (not just GitHub).

7c6f434c commented 6 years ago

As I have already mentioned, there are not only fully libre smartphone apps available in F-Droid (not requiring Google Play Services and working well on LineageOS)

I implore you to show me a reasonably secure (either with no radio, or with free firmware for radio modules) device that can run LineageOS.

I would expect that the most promising way is to actually put a wrong firmware blob and just make the component reject it and hang; not sure for which phone it doesn't hang the rest of the phone.

oathToolkit Wait, so you're saying that I can use oathToolkit + zbar in place of a smartphone?

Yes, and zbar is only needed for initial setup.

Macs have "memory chips of unknown purpose" on their motherboards too, btw.

Well, are there any CPUs above 1 GHz that don't list a kind of non-user-controllable CPU-in-CPU in their official specs?

But if I can just run oauthToolkit + zbar to emulate 2FA on my laptop, then

  • I retract the handcuffing argument,
  • I ask what is the point of all of this then exactly?

Seems like 0.33x the efficiency with 0 more security to me.

No zbar needed — would use a script that asks pass to decrypt your password and also ask oathtool to generate the code. But you need a form submission in-between, so cannot paste at once, that's true.

There is a bit of extra security — passively keylogging the GitHub VM doesn't yield enough data for long-term compromise, and token creation causes an email notification.

And as I said: a messed-up 2FA setup is probably still less vulnerable to bulk attacks than silly password reuse, and there is no way to verify if the latter has occured…

orivej commented 6 years ago

This is the first time I'm faced with 2FA and I don't know what to expect. Common sense suggests that I should not enable it for my main account because it will either (1) decrease my security (if I'll be able to log in without the password with the second factor, e.g. in case I have lost my password or my email), or (2) be able to lock me out even though I am still in possession of the password and the email, or (3) have no effect on security but decrease convenience. Therefore I have created a new account, @orivej-nixos, with 2FA. @grahamc, could you make it a member of @NixOS?

P.S. My computer is the only device that I trust, and I also don't want to depend on the second factor that I can not backup and restore, or that is a separate physical object. Luckily GitHub has let me enable 2FA on the computer alone. Even zbar was not necessary: on the screen with QR code it asks if you can not scan the image and want to type the code instead; I ran oathtool --totp -b the_code and pasted the output into the browser. That pleased GitHub.

oxij commented 6 years ago

Many words (TL;DR is below)

Macs have "memory chips of unknown purpose" on their motherboards too, btw.

Well, are there any CPUs above 1 GHz that don't list a kind of non-user-controllable CPU-in-CPU in their official specs?

Sandy Bridges without Intel ME blobs do 2+GHz. But without user-modification, sadly, there are none, yep.

That's a different issue, however. "State about you that you can't control" is not the "computation you can't control". The former is worse, as the latter can be simply fed with false data.

There is a bit of extra security — passively keylogging the GitHub VM doesn't yield enough data for long-term compromise, and token creation causes an email notification.

I don't think long-term source code compromise is likely in a FLOSS project anyway. Too many eyes. I regularly audit changes to projects I use heavily before updating (including nixpkgs; pretty easy to do, btw, just mark your revision with git branch -b last-review and then git fetch ; git log --reverse --format="%H" last-review..nixpkgs/master | xargs -n1 -I{} git show {}, record revs of all the untrivial changes, and then review them extensively, rinse and repeat). I understand that most people don't do this, but even the small number is enough. (Having a distributed web-of-trust system for this where you could sign-off already commited patches, preferably with a confidence level (like "LGTM", "careful LGTM", "careful LGTM, 1 level of recursion into deps careful LGTM", "security audit", etc), would be nice, though.)

Meanwhile, there's just no way around two+-person sign-off if you want to defend against a sneaky version of the source level attack (change something very subtle security-related, potentially with no actual compromise of member credentials necessary, as somebody could merge it without noticing).

But if I were the red team I wouldn't go for the git repo anyway, I would go for the Hydra cache as it provides much wider immediate impact while having much less visibility.

there is no way to verify if the latter has [not] occured…

This argument applies to Hydra as much as to user credentials. How do you know that members's passwords/2FAs are reasonably secure? You can't. How do I know that Hydra cache is reasonably secure? I can't. Which is the reason why I don't use Hydra cache at all.

As to

The point is to have at least some second factor.

and

And as I said: a messed-up 2FA setup is probably still less vulnerable to bulk attacks than silly password reuse, and there is no way to verify if the latter has occured…

I see that point, but I think it is a security theater that is bound to fail spectacularly against determined attackers, as outlined above. For-all-to-see source code level compromise is embarrassing, but it is of low impact even if that change gets into and compromises Hydra. After all, you get the whole source code of the attack.

What I would

What really needs defending is the path to the binary cache that doesn't involve the sources. That is to say, I would require all the core and most of the leaf packages to be reproducible and build everything on at least two separate infrastructures. which, btw, you already have, now all you need is to make GrahamcOfBorg to verify Hydra cache (via Tor, btw, or else Hydra could lie only to OfBorg) and vice versa.

As to the source level, as I mentioned on multiple occasions before, I would start by splitting nixpkgs into two repositories with a single tree: "package updates only", "everything else". This separation is easy to enforce by matching paths of changed files and it will make things significantly easier to discover (interesting things go into "everything else") and review ("package update only? only changes the minor version and the hash? still builds? LGTM!", which is trivial to check by automatically comparing drvs with OfBorg).

Then, the "packages updates only" part could be automated almost completely by feeding the output of @r-ryantm to @GrahamcOfBorg and verifying that stream of diffs with a simple script run by independent parties.

All other changes (including the merges of batches of diffs from "packages updates only" repo into master) should get multiple sign-offs.

TL;DR

In short, now that I know that I can play along with this security theater with oathToolkit and zbar, I'm :+0: over this issue.

I do think that 2FA is the least of our security-related problems, though.

aszlig commented 6 years ago

@oxij: Note about TOTP and pass: There is also gopass, which has support for TOTP and HOTP, so you only need zbar for the initial QR-code and then use gopass otp. Also @grahamc mentioned on IRC that there's also https://github.com/WhyNotHugo/totp-cli if you don't want to use gopass.

I also agree that turning off HTTPS-support is a better idea, especially if you have a cryptotoken where the private key isn't laying around on your disk. It turns out that enabling 2FA essentially disables HTTPS-support on GitHub, so IMHO this should be sufficient for the push-access side of the discussion.

orivej commented 6 years ago

I have checked that you don't need zbar: GitHub provides the textual code alongside the QR code.

7c6f434c commented 6 years ago

It turns out that enabling 2FA essentially disables HTTPS-support on GitHub

Interesting, I read the instructions and ended up successfully adding one more token to my password manager and pushing via HTTPS…

aszlig commented 6 years ago

@7c6f434c: Hm, weird... I tested that also but I wasn't able to push using the web site password. According to the GitHub documentation it should only be possible if you generate an access token.

7c6f434c commented 6 years ago

Yes, I did generate an access token as advised.

I mean, it is not really different from a password for push purposes…

aszlig commented 6 years ago

@7c6f434c: Now I'm confused: Do you mean Personal access tokens or a TOTP-token? With HTTPS being essentially disabled I meant that you can only use SSH-keys for pushing changes (which IMHO is desired), except of course if you use such a personal access token.

7c6f434c commented 6 years ago

I mean personal access tokens, and I would say their behaviour is not too different from passwords for practical purposes

oxij commented 6 years ago

@aszlig

Turns out there's also https://github.com/tadfisher/pass-otp that does all the oathToolkit and zbar magic already. Packaged in nixpkgs too.

aszlig commented 6 years ago

@7c6f434c: Now I'm even more confused: I never stated that the use of a personal access token would be more secure than a password. Maybe I wasn't specific enough with cryptotoken: I meant something like this or even a smartcard reader with a pinpad and a PGP smartcard.

@oxij: Ah, that's even better as it seems to be more actively maintained and it's even similar in the CLI of the gopass implementation.

7c6f434c commented 6 years ago

Well, you said it effectively disabled HTTPS, I think that the recommended path includes the instructions to set up a personal access token so not much changes for https push.

aszlig commented 6 years ago

@7c6f434c: Okay, then let me rephrase: You can disable HTTPS push access for your account by not generating a personal access token and enabling 2FA.

grahamc commented 6 years ago

I've marked most of the previous conversation as "Off Topic" due to some FUD around requirements, and to reduce confusion on this important and high-traffic issue.

oxij commented 6 years ago

@grahamc

I've marked most of the previous conversation as "Off Topic" due to some FUD around requirements, and to reduce confusion on this important and high-traffic issue.

I'm over the fact that most of my substantial comments on policy are usually "off-topic".

But how is https://github.com/NixOS/nixpkgs/issues/42761#issuecomment-402303113 by @orivej and the discussion of tools is offtopic?

What I see is that everything that wasn't clearly :+1: on the issue was marked as off-topic. Very impartial.

aszlig commented 6 years ago

I'm adding this for reference for others: Another alternative to pass-otp would be gopass, which can use the existing pass store tree format and has TOTP/HOTP-support.

grahamc commented 6 years ago

@orivej I believe your alter-ego @orivej-nixos has been added now.

Reminder to the following accounts about the July 6 deadline:

@amiddelk, @antono, @aristidb, @astsmtl, @bjornfor, @bluescreen303, @c0bw3b, @civodul, @cstrahan, @edwtjo, @errge, @gridaphobe, @lethalman, @maggesi, @mornfall, @MP2E, @obadz, @Phreedom, @pikajude, @qknight, @roconnor, @rushmorem, @ttuegel, @vbgl

grahamc commented 6 years ago

Note: I've added documentation on how to use a U2F hardware token for 2FA on NixOS: https://github.com/NixOS/nixpkgs/issues/42761

7c6f434c commented 6 years ago

Maybe also add pass-otp to the list?

grahamc commented 6 years ago

We're getting close to the cut-off, and we remain with the following people:

@amiddelk, @antono, @astsmtl, @bluescreen303, @c0bw3b, @civodul, @cstrahan, @edwtjo, @errge, @gridaphobe, @lethalman, @maggesi, @mornfall, @MP2E, @obadz, @Phreedom, @qknight

I've emailed everybody but @c0bw3b and @mornfall since I couldn't find email addresses for them.

Update: @edwtjo's email bounced.

Update: I've just now emailed @c0bw3b, after @Profpatsch pointed out I can find their email in the maintainers file.

tadfisher commented 6 years ago

U2F works in Firefox since commit https://github.com/NixOS/nixpkgs/commit/9595dc587f137fed1d611867c84bc71fa0776f48, actually, thanks to @tadfisher.

That pass-otp tool by @tadfisher works pretty well too. I should buy him a beer.

c0bw3b commented 6 years ago

@grahamc 2FA now enabled on my account. I checked my nickname on your list above.

grahamc commented 6 years ago

:heavy_check_mark: done! thank you, everyone!

cstrahan commented 6 years ago

@grahamc I've enabled 2FA -- could I be re-added to the org, please?

edolstra commented 6 years ago

@cstrahan Done.