GitHub will require 2FA by the end of 2023

I don’t think that’s an insane setup at all. Losing access to GitHub would be bad for a lot of folks on HN I suspect. My GitHub has 2FA with Yubikeys and I am planning to do something similar to yours with backing up to a personal Gitea instance… once I get around to it.

Would you be able to share the GitHub to GitLab backup script?

Nit pick, but I wanted to point out that backing up your cloud data (github) to another cloud (gitlab) is increasing (approximately doubling) your attack surface. Good for data retention though.

I just use different accounts for work and private stuff.

For me 2FA is super annoying because I run my browsers in private mode and I restart them multiple times a day, so I have to sign in quite often. It effectively makes it much harder for me to keep my privacy.

Not to mention loosing the freedom to log in to my accounts from everywhere without needing my devices. Things do get stolen/lost/destroyed and that is a more realistic threat for me than getting my password stolen.

Am I the only one that thinks that 2FA actually increases the probability of losing access to an account? It's only a matter of losing the 2nd factor.

There isn't be a need for a phone. TOTP (time based one time passwords) which Github supports is just an algorithm, you can (and many password managers have it too) run TOTP on the desktop.

Whether this is a good idea or not is up for debate, but it doesn't require a phone, or even internet technically, just an accurate (within ~1 minute) time.

EDIT: Typo should -> shouldn't

EDIT2: to be more clear- shouldn't -> isn't

All great points and very common cases, yet services that force 2FA seem completely oblivious to this or just don't care about responsible users. In instances where it must be a phone number it is obviously for data mining.

It is a lazy way to cater to the lowest common denominator of users who will eventually fall for a phishing scam or install some keylogger and have their password end up in a dump.

Having support that is able to resolve 2FA problem creates new issues - how to prevent attacker from social engineering their way around support to gain access to your account. It’s hard to verify the identity online, across borders.

IMHO there’s no good answers on global scale. Identity should be handled on local level. Government already has process for issuing me new tokens even if I would loose all my existing ways of proving my identity. Local organizations know how to verify my identity using those tokens. I already put lots of trust on my own bank on this, so maybe they could also manage my digital identity.

Had this happen to me in November when Android 12 corrupted my pixel 5 and I didn't have backup codes. Altogether it took 2 months before I was able to access everything again, the last thing I got access back to was my Xbox lol

> or at least keeping a mirror of everything on another provider,

GitHub is a remote. This "mirror" is kept on your disk.

> I think we all need to consider the possibility of moving off of GitHub,

I've come to that conclusion, too. I moaned and groaned when Microsoft bought GitHub, but did nothing about it. Now I've begun the migration process.

I'd like to spell out some big-picture thoughts on 2FA. Security and convenience are antithetical to each other. Sometimes better solutions come along where you can have a little bit of both. But ultimately, they're trade-offs.

Do you value security, or do you value convenience? And in what proportion?

Furthermore, increasing security also increases fragility. There's more to go wrong. Posters here have been talking about losing their devices, and so forth. These are legitimate concerns. These points have rebuttals, such as recovery procedures, and so forth. OK, and you're sure grandma is up to the task, is she? All these convenience tools: they're easy to use until they aren't.

So not only do you have to think about security vs convenience, you have to consider downside risks on both ends of the spectrum. It's not as easy as saying "moar security" and reading press reports about the advisability of such systems.

TOTP doesn’t have any shared identifier, just a shared randomly generated secret. FIDO2 generates unique IDs for each user/site pair, so there’s no mining possible even if a user uses the same hardware token for multiple sites.

> 2FA is used to get unique identifiers and data mine people.

How do they get unique identifiers from TOTP?

> flag any existing accounts as "2FA Not Enabled" so that users can use that information to make their own choices about which dependencies to include in their projects.

Fine, do that. I don't care. Just don't force me to use 2FA if I don't want to. I prefer the convenience over the extra security. This change removes that choice from everyone.

Mercy me, that's some mighty smart incentive centered design you done schemed up.

It's actually higher than I expected. I've mandated a lot of different contractors use MFA over the years and the fighting back has been depressing.

> The fact that GitHub assumes to be in this position is alarming.

it's kind of true, isn't it (for certain programming languages)?

I mean... they are the default home for most open source

I hate those paternalistic ethics. Your responsibility is not to get hacked. My responsibility is to make sure I don’t leak my credentials. Telling people how to live is not your responsibility.

It's hard to require a strong password. No matter what constraints you enforce, you'll always end up with various forms of P@ssword1.

2Fa is an excuse for we want more sales channels.

You can put an auth cookie in a browser and achieve 2FA for 99% of use cases without bothering anyone.

But nobody does that when they can use 2FA as an excuse to force people to install their app or hand over more personal information.

No reason 2FA can't be just two passwords.

U2F has been supported for a while: https://docs.github.com/en/authentication/securing-your-acco...

They let you enroll a hardware token after you enable either a TOTP or SMS 2FA method. No idea why, seems to defeat the point of the additional security that a hardware token offers.

This is odd - they sure do support WebAuthn, I've been using a YubiKey for years.

I use FIDO U2F since 2015.

I got my Yubikey from Github for $5 https://github.blog/2015-10-01-github-supports-universal-2nd...

I understand the SMS part, but what makes TOTP a not "meaningful" 2FA?

This change would certainly have helped against the infamous "Gathering weak npm credentials" research[0] from 2017, but I think that most recent supply chain security issues (in NPM, at least) have been due to: 1) typosquatting, 2) developers deliberately adding malicious (or unwanted) code into their own packages, and 3) deep transitive dependencies on packages that have genuine bugs that lead to vulnerabilities.

It's not clear that this 2FA requirement would fix any of those problems, but it could one day allow package management tools to flag up when one developer has given/sold control of their package over to someone else who has less of a reputation and might be malicious, as was the case with the event-stream package.[1]

[0] https://github.com/ChALkeR/notes/blob/master/Gathering-weak-...

[1] https://www.eweek.com/security/node.js-event-stream-hack-exp...

Not that I know of, but you should definitely at least enable a second form of 2FA like the recovery codes OR a second security key, then print/write/store the file/key somewhere. If you lose your primary, then you can use that secondary. Never just have 1 form of 2FA without a fallback.

I don't have a cellphone or usb dongle and don't want them.

I have used various products from yubikey they work well on both Linux and Mac and you can also store gpg keys on them for commit signing and so on

Install experience is not the best , but drivers work well

For security keys implementing FIDO (which sometimes you can see referred to as WebAuthn, although that is partially inaccurate), there is currently no good way of backing up the key. If you lose it, then you'll need to recover your account with every service you had it registed it with, meaning that you'll need at least an additional factor on each service that's most likely not as secure as a FIDO key, unless you're registering two keys for every service which is very cumbersome and still makes you re register a lost key with each service.

There are proposals to address this either by chaining trust between security keys or by sharing "passkeys" (a webauthn credential). see https://news.ycombinator.com/item?id=31272867 Only apple implements it today as far as I know so there's no good way to recover from a lost or damaged key if you're not exclusively in the apple ecosystem

Authy synchronizes across devices and works on a computer. If you're using Github then you at least have a computer. And using 2FA on your own computer at least guarantees that the access is from your computer.

Sure, someone could hack your computer and get access to your GitHub, but if they're already on your computer, they can just change the code and do a git push too.

github will give you backup codes you can print out and use in case somthing bad happens.

I personally have 2 yubikeys registered as the second factor and it works great. They last years w/o any problem.

I think you bring up a great point. How can people do 2FA well for their situations? This is a practical question and people make many assumptions. A lot of what I know isn't clearly documented.

Clearly communicating a bunch of different options would be helpful for people.

Personally, I have 2 yubikeys, Authy synced to multiple devices, and the backup codes. There a bunch of options with different tradeoffs.

They provide a set of single use recovery codes for that purpose. I keep an encrypted copy of them in cloud storage and in several physical backups, so in the event that I lose or don't have access to neither my main nor backup yubikey, I can very likely still dig up a recovery code (eg by calling up a relative and asking them to read me the code).

The provide 16 single use codes for the "my TOPT device blew up" case, enough to get you in and reset things.

And for people that are unable or refuse to use a secondary device, there's no technical reason you can't run a TOPT app on your desktop.

You can buy a couple of Yubikeys, and use one as backup.

Probably feasible for most users of HN, but prohibitively expensive for millions around the world. Using a phone for 2FA is not great:

1. You can lose it. 2. If you're backing up 2FA to the cloud, then it's not 2FA any more. 3. If you use a password manager on your phone, then both factors are the same, it's not really 2FA.

i am only using github infrequently. the risk of getting locked out scares me. the likelihood of me forgetting which device i used to enable 2FA and maybe breaking/loosing/reinstalling said device (while forgetting to back up the 2FA to another device, and never mind remembering where i put the backup codes that were created 10 years ago) is much greater than anyone breaking into my account.

the end result will be that i won't be contributing code on github anymore but rather copy the project elsewhere and tell the developers where to pull my patches from.

Worst case you'd have to download new one time codes every tenth login or something like that.

> Let's just remind ourselves that we're not born with attached cellphones.

2FA doesn't mean only SMS or smartphone app.

Use any password manager (you should already be using one) that has TOTP support such as keepassxc or 1Password. No cellphone needed.

bank sites do this too.. but they log you out after like 10 minutes of inactivity. The other day I was thinking of installing a plugin for firefox that will refresh a tab periodically. Not sure if that'll help the issue but worth a try.

isn't it just better to use an app such as 1Password that can keep all your one-time passwords?

This is why passwords are still king for many of us.

And that the very same reason people can't be trusted with passwords is the same as why they can't be expected to keep backups of their recovery codes.

Passwords suck. But so does every form of 2FA.

I made this mistake when I enabled 2FA for Uber some years ago. Same old story. Somehow forgot to grab my recovery codes for Uber even though I had for everything else. I got a new phone, manually transferred all my google auth codes from my old phone, somehow missed Uber. And then a few months later after I had already reset my old phone I installed the Uber app and oops, I needed a 2FA code. Couldn't get one. And because Uber is tied to your phone number I couldn't even just create a new account without getting a new phone number. So I emailed their support (which is useless), got a bunch of bot responses about how to reset your password, finally got one real person to respond after several weeks. But they had no idea what I was talking about and clearly had no ability to actually do anything about the 2FA issue. So I gave up and now I'm just permanently locked out of using Uber. Which is fine, cuz fuck 'em. Now I use Lyft exclusively. Which doesn't matter because in my experience every Uber driver is also a Lyft driver.

But then where did the 2nd factor go? I mean how is a recovery key meaningfully different from a password, except that it's a random string chosen by the service instead of by me?

Fear is being locked out is exactly why I'm reluctant to enable 2FA. To enable it and then just store the password (err, I mean, recovery key) in my password manager seems to just get me more hassle for exactly no additional security.

What am I missing?

Funny story, I did store my Github codes in 1pwd

Years go by, I need a code, they don’t work. Github could do nothing but tell me to start a new account.

Same old story; Github does not exist for you. It exists to make its workers and owners money. Whether it works or damages you is irrelevant to them.

The future has no obligation to the past. Don’t expect the codes to work if they change something that deprecates the old system they used.

I'll be honest.

I don't believe I have the capacity to reliably preserve, in a secure location, recovery codes from dozens of different services over many years.

I suspect I'm not the only one.

There is pretty much nothing else in my personal life I have to do something like this with. The closest might be my physical SSN card or birth certificate. But that's one thing to keep track of, not a new thing every week or month to add to the stash. And even those, if they get lost, there is SOME way to replace them, usually.

We are asking people to do something that is not a thing they have practice at or otherwise have to do or are any good at or have the capacity for. And then blaming them when they fail to pull it off, where you're constantly getting locked out of things and/or constantly getting hacked, probably both at once.

I understand passwords alone don't work. I don't have a solution. I'm just predicting a very painful digital future for most people.

(My own "solution" is using Authy TOTP, installing it on multiple devices, figuring I will retain working access to at least one of these configured devices, and not bothering with backup codes. I don't know how secure it really is, or TOTP is in general, but it lets me keep using services that require it, without living in fear that I'm going to lose my phone and misplace the backup codes and lose access forever).

Also print print out the QR code used to sign up for TOTP.

That way it's easy to enroll a new laptop/phone/yubikey.

Once printed out, put in a plastic bottle and bury it in your backyard :)

Easier than what? Not having any 2FA at all?

I don't really understand how it can be easier to break into a system if you need the username, the password and an SMS code, than if you just need an username and a password.

Obviously, SMS two-factor authentication is flawed. But one-time codes and WebAuthn are pretty good two-factor authentication methods to secure important credentials.

Using phone numbers as a second factor should be in line with using MD5 for password hashing. It doesn't mean that MFA (or hashing) are a bad idea, just that you need to deploy it properly for it to make a difference.

That's because SMS is not 2FA. Proper 2FA implementation should require FIDO, TOTP, etc. and not even permit SMS as a valid method.

You’re talking about a completely different thing, SMS for password reset. That’s completely distinct from SMS as a second factor for logging in, which is absolutely fine for almost all people’s threat models, even in places where SIM or telco attacks are feasible, since the SIM alone is insufficient to log in as you.

Sure, it’s common for sites to use your phone number both for 2FA and account recovery (whether single- or multi-factor—and single-factor account recovery is obviously a serious problem in a two-factor authentication environment), but the problem you’re complaining about is nothing to do with 2FA.

I think Fastmail hits the right balance, and explains it well: https://www.fastmail.help/hc/en-us/articles/360058752374-Usi..., heading “Why do I have to add a recovery phone number to set up two-step verification?”

SMS should not be considered a 2fa, TOTP or a youbikey is the minimum that you should be able to advertise as 2fa.

TOTP is one of the supported 2FA method. There's a lot of TOTP implementations that don't require having a separate device. And if you're not happy with any of them, this is such a simple protocol, you can write your own in one evening.

So, what happened to openid? I take it that it's no longer a thing.

Please, don't give them any more "good" ideas.

But it's significantly easier, like way way easier, to phish someone versus compromise a filesystem and extract SSH keys. And you can just add keys afterwords if you phish them, so why wouldn't you go the easy route? That's why phishing is still such a massive problem: because it works.

If your SSH key is encrypted, it’s 2FA.

Either way, it’s not phishable (unlike passwords) so it’s way safer.

Derive you SSH key from a GPG key stored on a YubiKey[1] and even if you comprise the machine you don't get the keys.

1. https://github.com/drduh/YubiKey-Guide

So ridiculous. Really hurts for smaller startups.

The only places that want SSO will be larger enterprises who don’t have a problem paying $$$ for an enterprise package. Tying SSO to enterprise plans is a great way to segment your market!

It shouldn't, unless they change something.

I'm already using 2FA with github and it doesn't impact anything else (including git / ssh).

You don't need to give your phone number to enable 2FA on github. They'll annoy you every few months to give them your phone number as a backup but you don't need to do that. I hope it's never required either.

I think a good compromise is to allow organizations to opt to require 2FA in order to access their repositories, and allow individuals to opt to require 2FA for write permissions in their repositories (public or private).

I think the argument has already been made for 2FA often enough though. So they probably just assumed everyone had heard it (wrongly perhaps?).

why do you need 2fa for either of those?

You joke, but device attestation is the next step, and the NSA are publicly pushing for it.[0] It's already impossible to get a burger from McDonald's using their app if you're using an unlocked bootloader.[1]

[0] https://art.tools.ietf.org/id/draft-fedorkow-rats-network-de...

[1] https://c.mi.com/thread-3882246-1-0.html

Why not just ... print out or write down the backup codes?

Okay, subreddit created: https://www.reddit.com/r/encrypted_gb_codes/

I mispelled gh as gb, but that makes it more memorable (Great Britain, world war II spies, the cryptonomicon partially taking place in the UK, easy peasy).

Okay, so where was I? Right, the encrypted backup codes! Here is the code

    encrypted = []

    secret_key = input('secret key: ')

    try:
        for index, character in enumerate(input('secret to encrypt: ')):
            encrypted.append(ord(character) ^ ord(secret_key[index]))
    except IndexError:
        print('Your key is not big enough to securely encrypt the secret!')
        print('Go play cryptopals to see why using XOR that way would be bad')

    print(''.join(hex(i) for i in encrypted))

Aaand the secret is live on reddit. For redundancy I need to plaster this everywhere (hiding it in public key exchanges would also be easy!), but this will do for now:

https://www.reddit.com/r/encrypted_gb_codes/comments/uj1fll/...

I'm using 2fa for email as well. It made my life more secure.

When I read this announcement I was happy because this means 2fa is getting even more known,.accepted and used.

They don’t. Reading the article would have answered that question.