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).
