I wonder how much of the negative connotation in ~every GitHub thread comes from the MS buyout vs the actual topic under discussion. Do people really dislike 2FA on something as important as source hosting?
But it's not important for a lot of people. Lots of people just create the occasional issue or some such. Almost no one is a maintainer of something important.
And overall it's just a hassle that adds zero security for me; I just have the tokens in the password manager next to the passwords (where else do I store it? I just have my laptop).
It's something that should be the user choice, based on how important the account is, personal factors, etc.
I would actually be far more frustrated by mandatory 2FA at login than if my GitHub account were compromised. I use it to star projects, and because you can't code search without being logged in; it's a bottom-tier account for me and 2FA means I'll probably just not bother. Why can't they gate sensitive features behind 2FA?
As an aside, I'm surprised I've never seen an async authentication system whereby PW gets you in, 2FA code is sent, and you can continue accessing the system in a limited way until you submit your 2FA code, instead of sitting on some intermediary page waiting a few minutes for the code to arrive.
2FA is a bigger problem to me than Microsoft. I'm not having electronics on me most of the time.
If i have to log in to Github from somewhere else, i call my landline and have SO read the 2FA code to me. But since this is cumbersome i try to get my stuff done without the Github login.
I do dislike it. I'd take back my only occasional contribution to a project not to be bothered by 2FA and I'm not submitting issues anymore to anything. Basically I'm using github in read only mode without logging in. When another customer of mine will use github I'll be back on it and I'll use 2FA, but at least they'll be paying me for the trouble. All my current customers are on bitbucket.
> Do people really dislike 2FA on something as important as source hosting?
"important" is a per-person individual decision.
A phrase that used to be very common is "mechanism, not policy".
The role of a vendor is supposed to be to enable mechanisms so that customers can implement whichever policy that best fits their needs.
The role of a customer is to choose and implement the policy that best works for them personally, using the mechanisms that the vendor provides.
It is fundamentally wrong for a vendor to impose policy, that's not their job. Nor do they have the information to correctly make that decision.
Some (few) people have important source code in their github account. I'd highly encourage those people to enable 2FA. Most people don't have anything important that anyone else uses, so adding the overhead of 2FA for them is beyond silly and purely obnoxious.
> The role of a vendor is supposed to be to enable mechanisms so that customers can implement whichever policy that best fits their needs.
this is where GitHub isn't a vendor; it's almost a social network as one account getting compromised could potentially cascade through projects. If you want to manage the risk profile that best fits you; you'd localize on GitHub Enterprise or other selfhosting.
Very well put. I work in info sec and I find Githubs 2FA requirement completely obnoxious.
Because you can't use passwords anymore, you have to set up tokens, which are often stored in the clear. It's actually less secure for me than a reasonable password and a lot more hassle to maintain.
Should be a choice I make. I use GitHub a lot less now than I did before, it's a pain to use now. Maybe I'll move to something else that respects my choice and threat model.
It somewhat breaks my workflow of downloading my (encrypted) password database from a private repo on GitHub when setting up a new computer. The keys used to generate TOTP codes are in the password database itself, so I can't use TOTP to log into GitHub.
So I have an email account without 2FA that receives the Github 2FA code.
Also if you really really hate two-factor authentication, e.g. due to psychological change resistance, there are multiple good alternatives like Bitbucket or Gitlab. Nobody is forcing you to use Github, and usually people do not even pay for it.
> Also if you really really hate two-factor authentication, e.g. due to psychological change resistance
Nearly all resistance to 2FA is because of fear of losing access to the 2FA device. I believe it's a well-earned resistance, because they've done a terrible job of explaining that there are alternatives in that case, such as special codes that you can write down and put in a safe.
GitHub prompts you to save backup codes when you set up 2FA, and every so often when you log in. I don't think that's a terrible job, it's pretty much the standard.
They also nudge you to set up multiple 2FA methods. I have the app, a passkey, etc.
I don't bother much with the special back-up codes (although I do store them just in case). I just make sure I have the TOTP plaintext shared secrets stored on multiple devices.
One of the reasons I use Microsoft Authenticator instead of others is it allows me to back up the configuration to the Microsoft cloud. I've already followed the restore process several times over the course of replacing phones and it works well.
If you're interested in contributing to projects that are hosted on GitHub, but aren't in a position to be making decisions about whether to migrate them, then yeah, you're forced to use GitHub.
I've given up on using GitHub. Nothing else I use requires 2FA, I don't have a smart phone, and figuring out an alternative just to post bug reports is a waste of my time, so I've taken to emailing the developers instead.
The complete lack of consistency in MFA requirements just show no one knows what the fuck they're doing.
DoorDash: Every time I need to enter an SMS code.
UberEats: Same thing, SMS code every time.
Grubhub: No MFA ever. Wonderful.
Twitch: Every couple days I need to enter a code sent to my email (because I won't give them my phone number which they really really want me to give them).
Reddit: no MFA requirement...for now. Given how fucking garbage they've become I wouldn't be surprised if they start enforcing it soon.
Amazon: no MFA requirement despite sometimes asking.
GitHub’s 2FA gives you the option to use SMS. But even for the authenticator method you don’t need a phone, most decent password managers nowadays support saving (and auto-filling) 2FA tokens.
There’s also the option to print/write down the one-time codes. Though the latter would admittedly be a bother if you log out frequently.
Sure, but I don't like any of those options. I don't want Microsoft to have my phone number, I have like 15-20 logins, which is small enough to keep on paper [1], so I have no password manager, and I always logged out of GitHub since I generally log in to things via a private window.
I really, really don't like being tracked, "filed, stamped, indexed, briefed, debriefed, or numbered", so avoid accounts as much as possible, and all the more so from megacorporations.
[1] Correction: I originally said 10-15 but I remembered a few that are in the Firefox password manager, like archive.org.
I used to enjoy sharing some code for the benefit of the community, although less and less since SAS business models, and now AI training.
Mandatory 2fa feels like a step towards 'MS GitHub Certified Developer & Contributor' program. How else do you 'secure the supply chain' without having identified and accountable developers.
This feels like a slippery slope fallacy. I don’t trust Microsoft and don’t think they have user’s best interests at heart, but 2FA is generally accepted as a positive thing industry-wide. They’re far from the only ones to require it. See for example PyPI.
Why is it a fallacy? I stopped distributing on PyPI before the switch to 2FA because I could see it also going the "Certified Developer & Contributor" route, which is what often happens with centralized systems.
PyPI's later switch to 2FA confirmed my belief that they going further along that slope.
Centralized systems are hard to manage. We've seen how Anaconda and readthedocs have switched their business models to get more funding. PyPI uses a lot of bandwidth, and needs people to manage all of the attacks and abuse.
And you know who has money? Big businesses who want someone else to manage their supply chain. And you know who has the time to help manage these systems? People working for big businesses.
PyPI was able to require a change to 2FA in part because there aren't effective alternatives, nor the easy ability to migrate from one to another. Those who don't want to be part of the "industry" have a high switching cost.
Also, what does "industry-wide" mean? I distribute packages (source and binary wheels) on my own server. None of my commercial customers have ever even asked about 2FA. And if I am in the same industry, I can assure you I have never placed that requirement on my suppliers.
> I distribute packages (source and binary wheels) on my own server. None of my commercial customers have ever even asked about 2FA. And if I am in the same industry, I can assure you I have never placed that requirement on my suppliers.
a.k.a the "just trust me bro" approach.
Unfortunately the days where we can rely on trust alone are largely behind us.
Supply chain security is a real thing, even if "security vendors" over-hype it to sound like an impending doomsday.
If you work in an important industry, a leaked password should not result in a malicious package being pulled that takes out your <car/power plant/pacemaker/ insert important thing here>.
So am I part of this industry or not? What even makes something an "important" industry vs. a non-important industry?
It seems odd how you point to "car/power plant/pacemaker" examples when few people with Microsoft GitHub accounts work in real-time systems, much less ones which risk human injury or death.
My business works with P.O.s, contracts, wire transfers, one-on-one interactions, customer knowledge of my 25 years of working in this field, and my ability to vet my customers.
That's where the "trust me" comes from, not bro-dom, not Microsoft with its long history of security failures.
I said if you are in an important industry, a single password should not be the only measure stopping malicious packages to be distributed on your behalf.
Your customers can trust you all they want, but can they trust packages are actually coming from you or a compromised account due to a leaked password.
I will say a status page that gives out red flags at least makes me trust it more.
The AWS status page might as well be static until there is massive outrage on the internet that shows it is completely down, then a single green light will turn yellow or red after HR or Marketing have confirmed that there is no hiding the outage.
A lot less than what your average 'I just reuse the same password on a million sites' or your average 'my password is "iloveyou8", you see, the 8 makes it secure!"' user gains from 2FA.
But it's not nothing.
If you get phished and enter both your password and TFA in a scam site, they can log in as you, but they will not be able to log in as you later on, and (presumably, if github configured their stuff correctly) them _changing_ your settings (either updating TFA or removing the requirement to use TFA) is either not possible without _another_ attempt to phish you, or will result in you at least knowing e.g. because you receive an email from them. In contrast if they have your password and that's all that is needed to log in, they can now log in as you for however long until you change your password, and you won't know.
Similar benefits apply if your hardware is compromised due to a keylogger. Or, much more plausible, some tool is watching your clipboard. Which _will_ see the password, but _will not_ see your TFA unless you're also copy pasting that on the same device.
If the device that stores your generated passwords is itself compromised and you store your 2FA stuff elsewhere (a good general principle!) then it helps _quite a lot_. Trying to 'fake it' without 2FA is quite complicated; you'd need to store half of your password on one password vault and the other half on another and combine them by hand.
It depends a bit on your theory about how security is best done. if you ascribe to the swiss cheese model (where you layer quite a few slices of swiss cheese on top of each other with the aim that whilst each slice has holes, the stack does not have any holes), then these are quite a few added slices.
Thanks. I like the resistance against reading your clipboard, and I assume this is possible as a non-root application on Linux such as a steam game that I started.
Phishing awareness I have with the exception of dumb moments.
TFA on two devices I have as well but most my techyish colleagues actually don't, especially not for stuff that's easily done on the phone such as banking/crypto :-/
> If you didn't configure 2fa yet, the time has come to do it.
The time has come to ditch GitHub.
A while ago I barely managed to create an account using an email alias that worked (instead of providing my actual email). Within minutes GitHub deleted my account for some reason. I suspect it’s because I used email alias, but I really have no idea why.
GitHub is not forcing you to use 2FA to store your repos elsewhere. Just to interact with their website.
> I should get to decide the appropriate level of security.
People are really bad at deciding the appropriate level of security.
GitHub hosts a lot of very important projects that have impact in the real world. Forcing people to use the bare minimum to keep that environment relatively secure is probably not a bad idea.
That way when you set your password as "batman123" and are given commit access to some obscure project that is included as a dependency in 1000 other projects, your account is much less likely to be taken over as a means of pushing a malicious commit.
An email alias is typically an email address that redirects to your true email address. Which is conceptually fine, but the OP hasn’t shared specifics so for all we know they used a temporary email address from a service that spammers use.
And GitHub does have a spam problem (if you haven’t dealt with it yet, consider yourself lucky). Just the other day someone opened an issue in one of my repos and in less than a minute two spam accounts replied with links to download malware. Fortunately I caught them right then and there, deleted the comments, and reported the accounts to GitHub which banned them soon after.
2FA is superfluous if you’re using high entropy passwords stored in a password manager that incorporates phishing protection mechanisms (e.g. refusing to fill / warning when domains do not match).
Until the password manager is hacked/leaked. See: lastpass breach.
Protecting the security of multiple devices is much easier than maintaining, rotating, and securing cryptographically secure passwords. Ideally, as with most things in security, do both. There’s no real reason to eschew 2FA other than “I hate typing in a code sometimes.”
> Until the password manager is hacked/leaked. See: lastpass breach.
Certainly. If we're considering password manager compromise, it's also reasonable to include compromises of all 2FA mechanisms. Users can often have 2FA creds phished just by calling them ("something is wrong with your account, please read the 2FA code to verify your identity"). Sure, you and I wouldn't fall for this, but there are plenty of retirees out there who have. At that point, neither 2FA nor password manager would save them. You could compromise the password manager by social engineering ("add evilsite.ru to the allowed sites") or even by supply chain attacks (create a build that permits evilsite.ru). Since supply chain attacks are a reasonable hack against password managers, the same could be said about 2FA apps.
Consequently, we don't get anywhere productive in this discussion by assuming software compromise into the threat model.
I don't really understand the point you're making. Certainly any method can be compromised - I'm not claiming that 2FA can't. In fact, the post you are responding to says ideally, do both. This is sort of why defense in depth is a concept. Even in your example, the 2FA compromise also involves first compromising the password/login credentials.
> In fact, the post you are responding to says ideally, do both
Right, I said that even if you do both, both can still be compromised simultaneously and independently. The discussion is more productive if we assume that the password manager can be made secure in the same way that 2FA can be made secure.
This returns to my original argument that “assuming a secure password manager with phishing protection, 2fa+password provides no more security than a high entropy password.” Before we go there, this also includes the unstated assumption that the website also leaks only useless information to an attacker (salted hashes that would require centuries to brute force).
Spending 1 minute setting up 2FA is really not a big deal.
[1] https://github.blog/news-insights/product-news/raising-the-b...