Tell HN: GitHub locked me out for not using 2FA
Effectively 2fa is now mandatory for all accounts, not only commiters. If you didn't configure 2fa yet, the time has come to do it.
PS: I didn't see this news, so posting it, sorry if I'm slow
PS: I didn't see this news, so posting it, sorry if I'm slow
69 comments
[ 4.9 ms ] story [ 132 ms ] threadGitlab's currently on fire, don't worry about it. https://status.gitlab.com/
Also, really, nowadays everything should be MFA or SSO backed with MFA.
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.
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.
I don’t like that Spotify asked me for a valid credit card, so I’m cancelling my 30 day free trial. I don’t listen to much music anyway.
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.”
Not even that is a good reason for someone who uses a password manager. Most of them today allow storing your 2FA key and auto-fill them.
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.
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).
If someone can open the handle they can kick down the door as well.
1) They are my repos. I should get to decide the appropriate level of security.
2) 2FA is often used as a pretext for identity harvesting which are then abused for other purposes.
3) If there is account recovery via email then the whole thing is a charade anyway.
Okay, but there are many options, like TOTP code generators, that do not even require the internet to work.
> 3) If there is account recovery via email then the whole thing is a charade anyway.
You can disable all account recovery options in Settings.
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.
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.
Spending 1 minute setting up 2FA is really not a big deal.
[1] https://github.blog/news-insights/product-news/raising-the-b...
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.
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.
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.
"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.
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.
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.
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.
There is an unofficial method by using devtools on the desktop app, but it's been EOL for months and it may soon stop working completely.
They also nudge you to set up multiple 2FA methods. I have the app, a passkey, etc.
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.
GMail: no MFA requirement despite also 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.
Point being there’re many ways to go about it.
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.
So I have an email account without 2FA that receives the Github 2FA code.
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.
https://blog.pypi.org/posts/2024-01-01-2fa-enforced/
npm is another one, but because it’s owned by GitHub (and thus Microsoft) we can leave it out of the argument.
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.
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 use generated passwords and I check the URL before c+p'ing my password, what do I gain with it?
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.
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 :-/