GitHub will require 2FA by the end of 2023(github.blog)
github.blog
GitHub will require 2FA by the end of 2023
https://github.blog/2022-05-04-software-security-starts-with-the-developer-securing-developer-accounts-with-2fa/
312 comments
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.
You can have multiple second factors. I have 2 YubiKeys (one on me, one in a safe place) and then I have the standard TOTP codes on my phone using Authy.
If I manage to lose my phone, live and backup yubikeys then I have recovery codes.
It's going to have to be something pretty drastic to cause me to loose all of that.
If I manage to lose my phone, live and backup yubikeys then I have recovery codes.
It's going to have to be something pretty drastic to cause me to loose all of that.
No, we're here with you. I'm also wondering if being responsible for storing and using passwords is THAT BIG OF A DEAL???
Even mathematically, probabilities of two failing points are adding.
I've been locked away from mail, banks and gods know what else just because I didn't have my phone or computer nearby, was in different country, in a place without network coverage, haven't paid for cell in time, etc. etc. etc. and absolutely positive that 2FA (at least that requiring on-line presence) is evil.
The ONLY THING that can really protect and help you - is good HUMAN tech support. Where you can call, explain yourself, prove ownership and regain access to a service. Up to the point of having to go to of video-call office yourself and beyond. Yeah, I'm completely aware that some corporations don't even have humans (hello, Goolag!) employed - and trying to stay clear from them.
Well, I've lost control of accounts and I suspect a few of us have. Fortunately the one I lost wasn't important.
But my response wasn't to turn off 2FA. It was the reverse - to turn on all forms of authentication made available, for all acccouts. If I lost control of it one way, I had another.
By the by, if you read the spec, FIDO expects you to do this in preparation for the day you lose your token. So no you are not the only one - people think about it all the time.
But my response wasn't to turn off 2FA. It was the reverse - to turn on all forms of authentication made available, for all acccouts. If I lost control of it one way, I had another.
By the by, if you read the spec, FIDO expects you to do this in preparation for the day you lose your token. So no you are not the only one - people think about it all the time.
What people should do is have a small SD card with all of their private keys and passwords stored away safely. This SD card should be kept in cold storage (e.g. in a safe where you keep personal belongings), and never be accessed unless in absolute emergency (lost your YubiKey etc and can't get in anywhere, etc.)
SD cards are horrendous for long term storage. Probably the worst medium for such a task.
What is the best? Cursory googling suggests SD cards last ~decades at normal usage [0], and in this context where it's barely accessed, maybe longer?
[0] https://www.sdcard.org/consumers/faq
[0] https://www.sdcard.org/consumers/faq
Probably depends on the quantity of data. If you're talking GB's or TB's of digital data, then maybe "archival grade" DVD's or BluRay's.
https://www.verbatim.com.au/product-category/data-storage/op...
If it's instead just a few short strings of text (eg GH password recovery codes), then you could use physical storage.
eg engrave the codes into something that'll survive extremes (granite?), and keep them in a fire proof safe.
Or something along similar lines. Probably don't engrave into glass though, due to that potentially shattering in some situations.
https://www.verbatim.com.au/product-category/data-storage/op...
If it's instead just a few short strings of text (eg GH password recovery codes), then you could use physical storage.
eg engrave the codes into something that'll survive extremes (granite?), and keep them in a fire proof safe.
Or something along similar lines. Probably don't engrave into glass though, due to that potentially shattering in some situations.
If you go to bluray.com you probably can read the same only for blu-ray.
Better search for a neutral source.
Better search for a neutral source.
I wrote some scripts to generate QR codes, then printed them to photo paper.
https://github.com/alexjh/gpg-backup/blob/master/Makefile
Back then I thought that QR codes were a bit of a gimmick but now I'm way more confident that I'll be able to read them in the future.
https://github.com/alexjh/gpg-backup/blob/master/Makefile
Back then I thought that QR codes were a bit of a gimmick but now I'm way more confident that I'll be able to read them in the future.
My choice are 8cm DVDs of decent quality. And inability to quickly overwrite/damage your data is a bonus.
laser print
Do most people have a "safe where they keep their personal belongings"?
i guess it would presumably be on-premises, because you're going to have to take it out to add recovery codes to it every time you add a new TOTP or whatever (or create a new private key or password) right? If it was, say, a safety deposit box at a bank, odds are it's not gonna wind up with most of your stuff. Even on-premises, the task of making sure "cold storage" stays sync'd with my evolving passwords, private keys, TOTP recovery codes, etc, seems like something I'm unlikely to keep up with.
i guess it would presumably be on-premises, because you're going to have to take it out to add recovery codes to it every time you add a new TOTP or whatever (or create a new private key or password) right? If it was, say, a safety deposit box at a bank, odds are it's not gonna wind up with most of your stuff. Even on-premises, the task of making sure "cold storage" stays sync'd with my evolving passwords, private keys, TOTP recovery codes, etc, seems like something I'm unlikely to keep up with.
I have an IronKey for this purpose.
For that there are the revoke code. And the backup phone number.
Or even better than the one time codes they give you, you can simply store the secret itself, on a piece of paper in a safe.
easily solved by adding multiple MFA options, e.g. multiple security keys.
Github has alternative recovery methods though too, such as 2FA over SMS.
And support can help out as long as you can show that you can ssh into a github host using the private key of one of the public ssh keys assigned to your account.
That makes some sense, and seems to me a nice option. Is it documented anywhere that that is an option, that they will do that?
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.
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.
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.
Meanwhile, some use github once a year to file a bug report against an OSS project.
Tiered access would be better here. No commits, repos without 2fa.
Tiered access would be better here. No commits, repos without 2fa.
The post is talking about 2FA for
> active contributors (for example, those who commit code, open or merge pull requests, use Actions, or publish packages)
So it may not be required to simply file a bug report.
> active contributors (for example, those who commit code, open or merge pull requests, use Actions, or publish packages)
So it may not be required to simply file a bug report.
It's clear in the article's title, subtitle, first paragraph and bold quote thing that this does not affect someone handling issues and not code.
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.
This assumes that the "attacks" you're concerned with preventing are exfiltration of data, rather than mutation/deletion of data.
Would you be able to share the GitHub to GitLab backup script?
I appreciate that there's a response to the 'supply chain attack' issue, but this also seems like we're raising the bar further for participation. I'm still dubious as to whether a phone is required but even if it's not, this now puts a high bar for anyone who doesn't have a phone and creates all sorts of anonymity issues for people that do.
Git is decentralized. My feeling is we should be focusing on technologies that lean into that idea.
Inter-Planetary Version Control [0] looks to be a defunct project but hits the keywords that fit what I imagine to be a viable alternative. Does anyone know other alternatives?
[0] https://github.com/martindbp/ipvc
Git is decentralized. My feeling is we should be focusing on technologies that lean into that idea.
Inter-Planetary Version Control [0] looks to be a defunct project but hits the keywords that fit what I imagine to be a viable alternative. Does anyone know other alternatives?
[0] https://github.com/martindbp/ipvc
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
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
Can you provide some more context? In theory TOTP doesn't need a mobile phone (I guess) but in practice this is about whether GitHub, or anyone else, provides non-mobile 2FA options, either as an app running on the phone or by receiving a text message, say.
See https://docs.github.com/en/authentication/securing-your-acco... . I've only skimmed but I don't see anything in that list that doesn't require a mobile phone in one form or another.
See https://docs.github.com/en/authentication/securing-your-acco... . I've only skimmed but I don't see anything in that list that doesn't require a mobile phone in one form or another.
You should try reading it instead of just skimming it. Their steps for using TOTP (the first list of steps!) do not say anything about putting in a mobile phone or list any requirements about adding a mobile phone.
Then at the bottom for using a security key, it says "You must have already configured 2FA via a TOTP mobile app or via SMS". A TOTP app does not give out your phone number, does not rely on network connectivity, and does not require you use a mobile phone to use.
So 2/3 of the options absolutely do not require you give Google your phone number.
Then at the bottom for using a security key, it says "You must have already configured 2FA via a TOTP mobile app or via SMS". A TOTP app does not give out your phone number, does not rely on network connectivity, and does not require you use a mobile phone to use.
So 2/3 of the options absolutely do not require you give Google your phone number.
The answer is that many of the applications listed under "mobile apps" have a desktop version that one can use. I did only skim but doing a little more link diving on the prompting of other siblings comments in this thread shows that most of those programs have desktop versions.
Your comment would leave the reader confused, including myself had I not dug deeper into each of those links, because you don't address the fundamental issue. The GitHub page says "mobile app" even though many of the applications can be installed on desktop.
The line "You must have already configured 2FA via a TOTP mobile app or via SMS" further confuses the issue because this implies anyone wanting to use 2FA would need a mobile phone, which was precisely my point. A TOTP that doesn't give out your phone number, but still requires a mobile phone to use, technically doesn't need a working phone to use but practically does require a phone, so it's a kind of pedantic point you're making.
Phones are a huge attack surface, if not from scammers then from applications, businesses or governments wanting to use it to monitor usage.
Your comment would leave the reader confused, including myself had I not dug deeper into each of those links, because you don't address the fundamental issue. The GitHub page says "mobile app" even though many of the applications can be installed on desktop.
The line "You must have already configured 2FA via a TOTP mobile app or via SMS" further confuses the issue because this implies anyone wanting to use 2FA would need a mobile phone, which was precisely my point. A TOTP that doesn't give out your phone number, but still requires a mobile phone to use, technically doesn't need a working phone to use but practically does require a phone, so it's a kind of pedantic point you're making.
Phones are a huge attack surface, if not from scammers then from applications, businesses or governments wanting to use it to monitor usage.
> implies anyone wanting to use 2FA would need a mobile phone
I will acknowledge they probably shouldn't use the terminology "mobile app", but the most common way for people to use TOTP is with a mobile app which does TOTP. FWIW, there are many ways you can run a "mobile app" without using your primary phone, tablets also run "mobile apps" and there are tools to run such apps on your computer locally. This doesn't in any way give the service any kind of connectivity or access or tracking of your phone, and TOTP does not use any kind of network connectivity to operate.
I'll agree the above is a pedantic point to be making, and I agree their documentation could be better worded, and I can understand there being a bit of confusion. However whether or not you need to use a mobile phone, if the solution is TOTP a la Google Authenticator/Microsoft Authenticator/LastPass/Authy/1Password (RFC 6238), the answer is always no. RFC 6238 does not require phone numbers, it does not require network access, its purely hashes on the current time and an initial shared secret.
https://www.rfc-editor.org/rfc/rfc6238
I will acknowledge they probably shouldn't use the terminology "mobile app", but the most common way for people to use TOTP is with a mobile app which does TOTP. FWIW, there are many ways you can run a "mobile app" without using your primary phone, tablets also run "mobile apps" and there are tools to run such apps on your computer locally. This doesn't in any way give the service any kind of connectivity or access or tracking of your phone, and TOTP does not use any kind of network connectivity to operate.
I'll agree the above is a pedantic point to be making, and I agree their documentation could be better worded, and I can understand there being a bit of confusion. However whether or not you need to use a mobile phone, if the solution is TOTP a la Google Authenticator/Microsoft Authenticator/LastPass/Authy/1Password (RFC 6238), the answer is always no. RFC 6238 does not require phone numbers, it does not require network access, its purely hashes on the current time and an initial shared secret.
https://www.rfc-editor.org/rfc/rfc6238
I use TOTP on my desktop via a hardware key. There are many ways to do 2fa without phones as long as the provider does not consider 2fa to equal sms.
#1 says TOTP mobile app but any desktop app would work.
1Password is in that list.
Yes,all good points. Many vanilla javascript scripts are available to get this TOTP. The service provider can increase this 30 seconds (technically not, they just accept any 1 current time token = 30 seconds, any 3 token, 1 past, 1 current, 1 next = 90 seconds, and any number of past present tokens) to any multiple of 30 seconds. My personal scripts use 3 minutes.
> There isn't be a need for a phone.
You might need an "EDIT3", I'm afraid, because "isn't be" doesn't make that sentence much more clear.
You might need an "EDIT3", I'm afraid, because "isn't be" doesn't make that sentence much more clear.
Show me a TOTP implementation that doesn’t require a phone number to sign up for or initialize…
IME, they not only require a phone number at setup but, further, reject VOIP/twilio numbers.
This shows that it’s not at all about security, but about slowing (but not solving) their brutal, unrelenting, spam and sock puppet problems.
EDIT: Thanks - very interesting. I guess I am jaded by my experiences with 'authy' and twilio, etc.
IME, they not only require a phone number at setup but, further, reject VOIP/twilio numbers.
This shows that it’s not at all about security, but about slowing (but not solving) their brutal, unrelenting, spam and sock puppet problems.
EDIT: Thanks - very interesting. I guess I am jaded by my experiences with 'authy' and twilio, etc.
TOTP never requires a phone number. On GitHub, they either show you a qr code you can scan in an app, or a text you can import. All apps support this sign up process, from google authenticator to console-based tools like totp[0].
Other 2FA implementations may require phone numbers. But HOTP and TOTP don't.
[0]: https://github.com/arcanericky/totp
Other 2FA implementations may require phone numbers. But HOTP and TOTP don't.
[0]: https://github.com/arcanericky/totp
TOTP itself doesn't require a phone number, but the Authy phone app from Twilio managed to screw up their TOTP implementation and it requires a phone number. I filed a bug with them and they finally acknowledged that it's deeply embedded in their implementation.
Well, for starters, Github. I don't have a phone number on file with them and I have TOTP and FIDO available.
The vast majority of sites I use TOTP on didn't require a phone number for the account.
The vast majority of sites I use TOTP on didn't require a phone number for the account.
Free services with 2FA are a recipe for problems. You will eventually have your phone stop working, you will lose your hardware fob, and you will lose your recovery codes that you forgot where you hid. There is no paid support, so you get what you pay for. Trying to get back into your account, if it's even possible, will take a long time and lots of work. If you are abroad and need access, you might be screwed. If it's not hard to get back into your account at that point, their security sucks.
I think we all need to consider the possibility of moving off of GitHub, or at least keeping a mirror of everything on another provider, and making sure any long-lived services that pull from GitHub know the other provider to use. You don't want an account lockout to mean you've lost all your work.
I think we all need to consider the possibility of moving off of GitHub, or at least keeping a mirror of everything on another provider, and making sure any long-lived services that pull from GitHub know the other provider to use. You don't want an account lockout to mean you've lost all your work.
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.
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.
> 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.
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.
> Do you value security, or do you value convenience? And in what proportion?
Or to look at this from the threat analysis side, there are many different threat models and not everyone has the same ones.
This is why it is so wrong for these cloud services to consider only one single threat model and impose it on everyone.
Denial of service is also a consideration in threat modeling and 2FA does increase the risk of loss of access. Whether that's worth it depends entirely on other factors which will vary for each individual and group. It's never a clear cut answer.
Personally I have TOTP enabled on my github account (not on a phone, that's too fragile) but that's because it makes sense for my use case.
There are other provider accounts where I have no desire to ever enable 2FA because I value access from anywhere with only my memory far more.
Cloud providers should not be making threat modeling decisions on behalf of users, each user needs to make their own.
Another reason to self host most things, you can implement your own best policy.
Or to look at this from the threat analysis side, there are many different threat models and not everyone has the same ones.
This is why it is so wrong for these cloud services to consider only one single threat model and impose it on everyone.
Denial of service is also a consideration in threat modeling and 2FA does increase the risk of loss of access. Whether that's worth it depends entirely on other factors which will vary for each individual and group. It's never a clear cut answer.
Personally I have TOTP enabled on my github account (not on a phone, that's too fragile) but that's because it makes sense for my use case.
There are other provider accounts where I have no desire to ever enable 2FA because I value access from anywhere with only my memory far more.
Cloud providers should not be making threat modeling decisions on behalf of users, each user needs to make their own.
Another reason to self host most things, you can implement your own best policy.
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
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.
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.
Other providers do recovery by asking for a "secret code" that was only transmitted to you when you first signed up, or you can tell them to put a passphrase on your account. The first is more like a recovery code (but smaller), the latter is a second password you never use for anything else.
Another solution is for users to upload identification documents when they sign up for the service. To recover your account, the service asks you to provide the documents again. This way it doesn't matter what the locality is, and you can provide literally anything (a picture of a duck!). Some providers have asked me to send a copy of my Driver's License before, but I don't think I had provided it to them before recovery, so that wasn't great.
A couple startups are beginning to build "identity" products that I imagine will cover a lot of this space. I expect soon there will be one company that everyone uses for identity, and then rather than be at the mercy of GitHub, we'll be at the mercy of Sauron's Eye.
Another solution is for users to upload identification documents when they sign up for the service. To recover your account, the service asks you to provide the documents again. This way it doesn't matter what the locality is, and you can provide literally anything (a picture of a duck!). Some providers have asked me to send a copy of my Driver's License before, but I don't think I had provided it to them before recovery, so that wasn't great.
A couple startups are beginning to build "identity" products that I imagine will cover a lot of this space. I expect soon there will be one company that everyone uses for identity, and then rather than be at the mercy of GitHub, we'll be at the mercy of Sauron's Eye.
[deleted]
> or at least keeping a mirror of everything on another provider,
GitHub is a remote. This "mirror" is kept on your disk.
GitHub is a remote. This "mirror" is kept on your disk.
You would be surprised how many people develop directly from github, either by using github’s web editor or a third party editor. Even if one does not do this, poor backup hygiene is the norm not the exception - for most devs I would would be willing to bet a sizable sum that github is their most reliable and longest lasting repository of code they have.
We need someone like Homakov again (https://arstechnica.com/information-technology/2012/03/hacke...) so people can access their own repositories without this bureaucratic nonsense.
If you have a strong password, is that really the biggest security threat? I highly doubt that. 2FA is used to get unique identifiers and data mine people.
It is a breach of confidence that large parts of the open source scene has trusted GitHub and now has to jump through new hoops practically every year.
If you have a strong password, is that really the biggest security threat? I highly doubt that. 2FA is used to get unique identifiers and data mine people.
It is a breach of confidence that large parts of the open source scene has trusted GitHub and now has to jump through new hoops practically every year.
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.
I don’t think it’s true for the hardware token. The initial registration sends information about the token to the website (but the website can tell the browser it doesn’t need it, IIRC).
WebAuthn supports sending an attestation certificate during the initial registration. But with an implementation according to the spec this certificate only identifies the model of the security key used and thus is shared across a 5 to 6 digit number of physical keys.
This attestation is meant to allow the service to verify that you use a "blessed" security key with certain security properties (e.g. only a YubiKey 5 they verified to be secure and not some random $5 key with broken RNG off Amazon).
This attestation is meant to allow the service to verify that you use a "blessed" security key with certain security properties (e.g. only a YubiKey 5 they verified to be secure and not some random $5 key with broken RNG off Amazon).
This is bad. This, for example, allows sites to accept only government-approved hardware keys with backdoors and do not accept self-made secure keys.
This doesn't make sense. As a website author, why would I visibly restrict the security keys to backdoored government keys, when I can simply give the government an invisible backdoor API or direct database access?
This is intentional, given that “self-made” keys have plenty of ways to be insecure, and the average user cannot tell the difference between a well made key and one that is either accidentally or intentionally defective in ways that affect their security.
FIDO2 is designed to maximize security for the majority of users, and the majority of users are using Yubikeys or other hardware-backed tokens provided by big players in their space.
FIDO2 is designed to maximize security for the majority of users, and the majority of users are using Yubikeys or other hardware-backed tokens provided by big players in their space.
> 2FA is used to get unique identifiers and data mine people.
How do they get unique identifiers from TOTP?
How do they get unique identifiers from TOTP?
> Today, only approximately 16.5% of active GitHub users and 6.44% of npm users use one or more forms of 2FA.
That's atrociously low. I know it's caveat emptor when it comes to FOSS, particularly as the nominal price is usually $0, but that really needs to be bumped up for anyone that is publishing packages to a public registry.
I hope they both mandate it for NPM and publicly flog^Wflag 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.
That's atrociously low. I know it's caveat emptor when it comes to FOSS, particularly as the nominal price is usually $0, but that really needs to be bumped up for anyone that is publishing packages to a public registry.
I hope they both mandate it for NPM and publicly flog^Wflag 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.
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.
> 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.
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.
Have you tried using something like a YubiKey? You literally just tap it and you're authenticated. No pulling out your phone and typing anything.
I don't want to use 2FA, and I certainly don't want to have to buy something to use 2FA. What is hard to understand about that?
It sounded like you didn't like the hassle of using TOTP from a phone which is most people's complaint when using 2FA. I was offering a basically zero friction, more user friendly alternative which provides both convenience and security.
But then I need to buy a YubiKey (€45), and set it up on my Linux machines which seems to require some PAM stuff, and lose one of the two USB ports on my laptop, and carry it around, and make a plan for when I lose it or when it breaks.
And the advantage is ... I don't know? If you have a strong random non-reused password I'm not seeing any. The only hypothetical advantage is when someone compromises your email account or desktop, but support departments tend to just reset 2FA if asked, so it's not actually a protection.
And the advantage is ... I don't know? If you have a strong random non-reused password I'm not seeing any. The only hypothetical advantage is when someone compromises your email account or desktop, but support departments tend to just reset 2FA if asked, so it's not actually a protection.
No need for "PAM stuff" on Linux, plug it in and it's ready to use as a 2FA webauthn device. I think you can use it for PAM but I've never tried.
You can set it up as a GPG smart card if you're that way inclined (which also means you can use it as an SSH private key as well). The advantage there is that your private keys are never on your machine which means they stay secure even if your machine is compromised which is nice.
As for MFA (YubiKey or otherwise), I believe the "hassle" is worth the inconvenience. It means that of my (single site, very complex) passwords are compromised in any way my accounts will remain secure long enough for me to change passwords.
You can set it up as a GPG smart card if you're that way inclined (which also means you can use it as an SSH private key as well). The advantage there is that your private keys are never on your machine which means they stay secure even if your machine is compromised which is nice.
As for MFA (YubiKey or otherwise), I believe the "hassle" is worth the inconvenience. It means that of my (single site, very complex) passwords are compromised in any way my accounts will remain secure long enough for me to change passwords.
Mercy me, that's some mighty smart incentive centered design you done schemed up.
> At GitHub, we believe that our unique position as the home for all developers means that we have both an opportunity and a responsibility to raise the bar for security across the software development ecosystem.
The fact that GitHub assumes to be in this position is alarming. Combined with this enforcement which I do not appreciate, I’m reconsidering my investment and will actively start migrating off of GitHub.
The fact that GitHub assumes to be in this position is alarming. Combined with this enforcement which I do not appreciate, I’m reconsidering my investment and will actively start migrating off of GitHub.
> The fact that GitHub assumes to be in this position is alarming.
it's kind of true, isn't it (for certain programming languages)?
it's kind of true, isn't it (for certain programming languages)?
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.
I mean... they are the default home for most open source
OK, what's wrong with requiring a very strong password and not having any recovery option? If you lost/forgot your password, that's it, kiss your account goodbye. It puts the responsibility on the user, which is good imo.
I've never lost a password. And the only time I lost a somewhat important account (Google) was because of their automated recovery system. If I could select "disable account recovery" the account would've never been highjacked... OK maybe it would've in a few decades when the average PC could bruteforce a 128 bit password in a reasonable amount of time and Google disabled rate limiting for some reason.
I've never lost a password. And the only time I lost a somewhat important account (Google) was because of their automated recovery system. If I could select "disable account recovery" the account would've never been highjacked... OK maybe it would've in a few decades when the average PC could bruteforce a 128 bit password in a reasonable amount of time and Google disabled rate limiting for some reason.
A colleague lost their phone and send an email to GitHub asking for a password and 2FA reset. It was sent from his account email and it was succesful. I found it weird because it means someone got access to his email Github would provide access to their account.
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.
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.
> You can put an auth cookie in a browser and achieve 2FA for 99% of use cases without bothering anyone.
Confusing, obviously incorrect.
> No reason 2FA can't be just two passwords.
Maybe somewhat less obviously incorrect, but still incorrect. Passwords can be phished easily, are managed by users, etc.
Confusing, obviously incorrect.
> No reason 2FA can't be just two passwords.
Maybe somewhat less obviously incorrect, but still incorrect. Passwords can be phished easily, are managed by users, etc.
If you can phish the pw you can phish the totp. People type it in right after they type in the pw.
Yes, but the TOTP is only usable once and cannot be reused across unrelated sites ("password stuffing"). And with WebAuthn / U2F the second factor is completely unphishable.
You cannot guarantee "completely unphishable", only that you cannot yet conceive of a way to do it. It's very dangerous to assume that something is completely secure.
WebAuthn binds the credential to the domain. Under the assumption that your web browser and security key is operating according to spec this is unphishable. If your web browser or key contains a bug, or the domain is breached then all bets are off anyway.
Yes, but you can't guess a TOTP. You can guess a password. But I hope that Github will make their FIDO2 support better.
Only if the user chooses a guessable password.
If you really must protect the user from themself (which I don't think you should, except in much more extreme circumstances), you can generate the password for them.
If you really must protect the user from themself (which I don't think you should, except in much more extreme circumstances), you can generate the password for them.
That doesn't make his point invalid. All this does is share your personal belief that passwords can be phished easily.
You know what is less secure than a password? A phone. A phone is a sim swap away from being hacked at anytime.
You know what is less secure than a password? A phone. A phone is a sim swap away from being hacked at anytime.
Yeah, a phone is an endless source of possibilities: every auth SMS is (not "can be", not "may be", but "by design") intercepted and logged. Every app can be breached remotely. Every interface, especially wireless, is a potential point of entry. Abundance of non-user-trusted components (like most processors, controllers and SIM). Possibilities of covert data exfiltration. Lots of sensors and ways of real human identification. Proprietary platforms and OSes that don't receive patches. A phone is the WORST thing to entrust your auth keys to.
I am against SMS 2FA.
> No reason 2FA can't be just two passwords
That's not two factors, that's one factor (something you know) twice, even if it is different passwords.
That's not two factors, that's one factor (something you know) twice, even if it is different passwords.
[deleted]
2FA satisfies the "something you have" authentication type. Passwords satisfy the "something you know" type.
>2FA satisfies the "something you have" authentication type.
In the general sense perhaps. As it's commonly implemented, no not really.
In the general sense perhaps. As it's commonly implemented, no not really.
Well, given that Github today doesn't seem to support meaningful 2FA (only TOTP and SMS), wouldn't it be good to fix that issue before starting to talk about requirements like these?
Maybe it's just my account, but I can't currently enroll my hardware token with Github in any way whatsoever.
Sure, they offer some 1.5FA, but why would I bother with that?
Maybe it's just my account, but I can't currently enroll my hardware token with Github in any way whatsoever.
Sure, they offer some 1.5FA, but why would I bother with that?
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.
Authenticator apps, and SMS help them derive you have identity -- which is more secure for them and you. Hardware token via WebAuthn (etc) is only more secure for you.
When they say "for the sake of security" they mean for them too.
There's a reason they want you to verify using one of the first two methods first.
When they say "for the sake of security" they mean for them too.
There's a reason they want you to verify using one of the first two methods first.
> Authenticator apps, and SMS help them derive you have identity
How do they do that?
TOTP (i.e. authenticator apps) is a simple algorithm where the value is derived from a secret key and current time. It certainly doesn't verify anything about you.
How do they do that?
TOTP (i.e. authenticator apps) is a simple algorithm where the value is derived from a secret key and current time. It certainly doesn't verify anything about you.
By making the initial TOTP secret different for everyone.
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 got my Yubikey from Github for $5 https://github.blog/2015-10-01-github-supports-universal-2nd...
Yet, if you go into the "enable 2FA" settings on Github, you only get the option to enable insecure TOTP or SMS.
Apparently, once you do that, you might be able to add proper authentication. But no word on whether that then replaces the obsolete methods you were forced to configure earlier.
But, yes, right on track to enforce 2FA in 2023, I see...
Apparently, once you do that, you might be able to add proper authentication. But no word on whether that then replaces the obsolete methods you were forced to configure earlier.
But, yes, right on track to enforce 2FA in 2023, I see...
Github requires [0] the first 2FA mechanism to be totp or sms. Thereafter, you can add a webauthn compatible hardware key.
[0] https://docs.github.com/en/authentication/securing-your-acco...
[0] https://docs.github.com/en/authentication/securing-your-acco...
Why though? That makes absolutely no sense.
Just technically it makes no sense. WebAuthn is a great technology that addresses many privacy concerns, but once they had an excuse collecting phone numbers they don't want to stop. Even though it's not the most secure method. Google, and many others are the same way.
2FA is often used as an excuse to obtain more PII from people, and to verify your identity, as a whole. Most businesses want to match logins to individuals, not roles. And that's what 2FA provides them.
2FA is often used as an excuse to obtain more PII from people, and to verify your identity, as a whole. Most businesses want to match logins to individuals, not roles. And that's what 2FA provides them.
How do they get my phone number from TOTP?
Since when is TOTP obsolete?
> Since when is TOTP obsolete?
Since about the moment that teams all over the world discovered they could just paste the enrollment QR code (a.k.a. private key) into their wikis, and thereby continue unlimited sharing of their role accounts?
So, I guess 30 seconds after its introduction?
Since about the moment that teams all over the world discovered they could just paste the enrollment QR code (a.k.a. private key) into their wikis, and thereby continue unlimited sharing of their role accounts?
So, I guess 30 seconds after its introduction?
U2F has been supported for a while: https://docs.github.com/en/authentication/securing-your-acco...
Oh, that's lovely UX... "After you configure 2FA, using a time-based one-time password (TOTP) mobile app, or via text message, you can add a security key"
So, after you enable a broken-by-design 1.5FA method, which you don't want, and which will further expose you to account takeovers, you can, possibly configure actual security.
No wonder these guys are raking in the big bucks...
So, after you enable a broken-by-design 1.5FA method, which you don't want, and which will further expose you to account takeovers, you can, possibly configure actual security.
No wonder these guys are raking in the big bucks...
I understand the SMS part, but what makes TOTP a not "meaningful" 2FA?
The TOTP "private key" can be easily cloned. Targeted malware, a database compromise at your app provider that you "securely" sync your settings to, or just a few minutes access to your "authentication" device, will do the trick.
> or just a few minutes access to your “authentication” device
Oh, come on. Your “hardware” “authentication” “key” can be stolen in mere seconds by someone with physical access. Clearly, we should dispense with that fake bullshit 2FA and require face-to-face verification. Drive to the GitHub office and let them run a DNA test to confirm your identity, or GTFO, amirite?
Oh, come on. Your “hardware” “authentication” “key” can be stolen in mere seconds by someone with physical access. Clearly, we should dispense with that fake bullshit 2FA and require face-to-face verification. Drive to the GitHub office and let them run a DNA test to confirm your identity, or GTFO, amirite?
There is no sync to provider servers on any TOTP implementation I use. Nor does a TOTP implementation need to be an application on a phone. Are you perhaps referring to the Google Authenticator or the Microsoft Authenticator apps when you refer to TOTP?
Manufacturers that sell the "meaningful" 2FA hardware tokens can manufacture and sell duplicate keys, they even provide this as a service when you want backup keys. What makes you think they don't "securely" make a few duplicates themselves?
Manufacturers that sell the "meaningful" 2FA hardware tokens can manufacture and sell duplicate keys, they even provide this as a service when you want backup keys. What makes you think they don't "securely" make a few duplicates themselves?
> There is no sync to provider servers on any TOTP implementation I use
That's hard to dispute, but will you accept https://guide.duo.com/duo-restore as a counterexample?
> Are you perhaps referring to the Google Authenticator or the Microsoft Authenticator apps when you refer to TOTP
No, I'm referring to the actual RFC 6283 TOTP protocol. Which uses a trivially-cloned single private key. Which is, see the example above, in fact trivially cloned 'for convenience' by at least one widely-used 'enterprise' security solution.
> What makes you think they don't "securely" make a few duplicates themselves?
Since that literally makes no sense if you know how hardware tokens work.
That's hard to dispute, but will you accept https://guide.duo.com/duo-restore as a counterexample?
> Are you perhaps referring to the Google Authenticator or the Microsoft Authenticator apps when you refer to TOTP
No, I'm referring to the actual RFC 6283 TOTP protocol. Which uses a trivially-cloned single private key. Which is, see the example above, in fact trivially cloned 'for convenience' by at least one widely-used 'enterprise' security solution.
> What makes you think they don't "securely" make a few duplicates themselves?
Since that literally makes no sense if you know how hardware tokens work.
This is odd - they sure do support WebAuthn, I've been using a YubiKey for years.
Wonderful news. Supply chain security is a disaster because developers won't opt into any kind of security features in the majority. Mandating 2FA is the obvious solution, and we'll all be radically safer for it.
Glad to see Github pushing this, I hope package repositories follow suit!
Glad to see Github pushing this, I hope package repositories follow suit!
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...
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...
Yes, it definitely does not solve every problem.
Fortunately no one is claiming that it does solve all problems, and I wasn't arguing against that non-claim. My point was, what percentage of supply chain issues (since that 2017 research) would have been mitigated by this policy change?
To be extra clear, I'm not saying "This is a bad policy because it only stops some attacks", I'm just trying to get a sense of scale for how much this will help and how much more work needs to be done.
To be extra clear, I'm not saying "This is a bad policy because it only stops some attacks", I'm just trying to get a sense of scale for how much this will help and how much more work needs to be done.
I have no idea how many attacks this would stop. I suspect the answer is, roughly, "some".
2FA has screwed me over in multiple instances over the years across different services.
Realizing one weekend away that I forgot to do a quiz for a uni course, trying to login to the course website on my phone and then remembering my hardware key is at home in my laptop.
Being forced to add a phone number to secure accounts I could not give less of a shit about but have to use for one reason or another, coming back months later to login, and realizing it's an old number and I'm locked out.
Emailing support in those cases and them just removing the phone number or changing it without any additional proof making the 2FA utterly useless.
Or emailing support and them asking me to send some drivers license or ID, then politely telling them to just delete my account because they never had that much info about me anyway.
2FA is a scourge. Just let me worry about my own security, if I care about your service, I won't make my password "asdfghjkl". In 99% of cases, that is fine and I have never had an issue.
Realizing one weekend away that I forgot to do a quiz for a uni course, trying to login to the course website on my phone and then remembering my hardware key is at home in my laptop.
Being forced to add a phone number to secure accounts I could not give less of a shit about but have to use for one reason or another, coming back months later to login, and realizing it's an old number and I'm locked out.
Emailing support in those cases and them just removing the phone number or changing it without any additional proof making the 2FA utterly useless.
Or emailing support and them asking me to send some drivers license or ID, then politely telling them to just delete my account because they never had that much info about me anyway.
2FA is a scourge. Just let me worry about my own security, if I care about your service, I won't make my password "asdfghjkl". In 99% of cases, that is fine and I have never had an issue.
Are there any downsides to security keys as 2FA? Are they using a single standard that shouldn't accidentally change or be deprecated for some reason? Is it possible to use them on mobile devices? Are there any risks they might break? Any issues with Linux support? Which particular security key would you recommend and why?
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
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
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 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
Install experience is not the best , but drivers work well
I don't have a cellphone or usb dongle and don't want them.
As far as complying with 2FA requirements without these, if TOTP is an option, one way is to use Authy with desktop client. It's free.
How secure it is I can't really say. But it will allow you to access services requiring TOTP without a cellphone or usb dongle.
https://authy.com/blog/introducing-authy-for-your-personal-c...
How secure it is I can't really say. But it will allow you to access services requiring TOTP without a cellphone or usb dongle.
https://authy.com/blog/introducing-authy-for-your-personal-c...
If you're as crazy as I am, it looks like oauthtool+gnupg2 can do TOTP via the command-line on Linux as well. I think it's just another function that my homeserver will take over (or maybe a container). At least I can easily integrate this new info into my backup system, unlike apps on my phone...
There is also an Authy linux app, but, sure, open source command-line sounds great.
you can get a tiny one and keep it plugged into your laptop
Okay so which one do I buy and how do I use it with ssh. The documentation is not specific.
The github.com documentation pages I read on this topic yesterday said the MFA requirement was for web sign-on and https GIT repo URLs. It explicitly said that SSH-based git repo access would not be affected. Has anyone seen contradictory statements published by github?
Edit to add: I mean SSH git access using a keypair registered with your account. (I don't know if there is some legacy option to use SSH with passwords, which I imagine would be discontinued if not already.)
Edit to add: I mean SSH git access using a keypair registered with your account. (I don't know if there is some legacy option to use SSH with passwords, which I imagine would be discontinued if not already.)
yubikey 5 nano, get two. i use it w/ ssh. took a little googling to integrate the gpg authentications key w/ ssh. instead of using ssh-agent, you'd use gpg-agent to manage the keys.
there are other integrations, for example, i can also unlock my mac w/ the yubikey.
there are other integrations, for example, i can also unlock my mac w/ the yubikey.
On gnome on fedora at least, I can have my gpg automatically unlock when I login to the desktop.
I already have two steps on GitHub with the authy app but I don't get it. Why is it not good enough to send an email with a code when signing in without a cookie for people who don't want to opt in to two steps?
The way I see it my authy is a vulnerability because if someone were to guess my authy phone number, they could technically grab all of my TOTP.
I don't get this spoon feeding. I mean I would sign up to two steps where I can but something doesn't feel right about the lack of choice.
I already have two steps on GitHub with the authy app but I don't get it. Why is it not good enough to send an email with a code when signing in without a cookie for people who don't want to opt in to two steps?
The way I see it my authy is a vulnerability because if someone were to guess my authy phone number, they could technically grab all of my TOTP.
I don't get this spoon feeding. I mean I would sign up to two steps where I can but something doesn't feel right about the lack of choice.
i hate checking email or looking at my phone for two step auth. either choice requires me to access another system. It requires far fewer steps to just tap the button on the side of the yubikey.
It's pricey but looks like it won't be too warty, thanks.
https://forums.freebsd.org/threads/yubikey-5-nfc-not-working...
https://forums.freebsd.org/threads/yubikey-5-nfc-not-working...
> Okay so which one do I buy and how do I use it with ssh. The documentation is not specific.
Oh crap, I was thinking this doesn't affect me because I already have two factors authentication but yes if I need to fish out my phone every time I need to git something (I use sash, not tokens) that requires authentication, I will definitely minimize what I do on GitHub.
Oh crap, I was thinking this doesn't affect me because I already have two factors authentication but yes if I need to fish out my phone every time I need to git something (I use sash, not tokens) that requires authentication, I will definitely minimize what I do on GitHub.
Let's just remind ourselves that we're not born with attached cellphones. These things get broken, lost, stolen, etc. Besides, some people do not own one. How will they solve the problem of folks getting locked out? And if anyone says there is a workaround for cases like this, then what problem is it solving?
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.
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.
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.
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.
This does not solve the problem of losing or breaking the device containing the key.
And it significantly degrades the user experience by requiring you have both devices available when you create an account to have any kind of backup.
And it significantly degrades the user experience by requiring you have both devices available when you create an account to have any kind of backup.
If you backup 2FA to the cloud (eg. authy) how does that not count as a second factor still even if security is diminished for other reasons?
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.
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.
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.
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.
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.
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).
> Let's just remind ourselves that we're not born with attached cellphones.
2FA doesn't mean only SMS or smartphone app.
2FA doesn't mean only SMS or smartphone app.
Worst case you'd have to download new one time codes every tenth login or something like that.
Yeah I can't see how it could be any worse than that.
Writing down a single new one time code after each login?
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 personally have 2 yubikeys registered as the second factor and it works great. They last years w/o any problem.
> github will give you backup codes you can print out and use in case somthing bad happens.
The backup codes have a "nearly never used" issue: since they're nearly never used, it's easy to forget where you put that piece of paper (I vaguely know where mine might be located, but I'd have to lose some time searching for it if I ever needed it).
And there's also the risk that the "something bad" affects both the TOTP device and the backup codes. If your home is flooded, for instance, you might lose to water damage both the piece of paper where the backup codes are and your mobile phone.
The backup codes have a "nearly never used" issue: since they're nearly never used, it's easy to forget where you put that piece of paper (I vaguely know where mine might be located, but I'd have to lose some time searching for it if I ever needed it).
And there's also the risk that the "something bad" affects both the TOTP device and the backup codes. If your home is flooded, for instance, you might lose to water damage both the piece of paper where the backup codes are and your mobile phone.
We had to buy yubikeys for various things since the whole cellphone thing wasn't going to work. You do have to buy multiple because of breakage or loss.
How do I actually do this? I want to keep using ssh. I don't have and don't want a cellphone. I use FreeBSD. I can't find a simple explanation in the docs.
Use any password manager (you should already be using one) that has TOTP support such as keepassxc or 1Password. No cellphone needed.
I use a key-pair for github ssh. I don't use any password managers, instead I have unique long passwords. What's my second factor without a cellphone?
You can use OATHTOOL [1] on the command line or even roll your own TOTP implementation [2] in just a few lines of code in your favorite programming language.
[1] https://www.nongnu.org/oath-toolkit/oathtool.1.html [2] https://datatracker.ietf.org/doc/html/rfc6238
[1] https://www.nongnu.org/oath-toolkit/oathtool.1.html [2] https://datatracker.ietf.org/doc/html/rfc6238
I don’t believe this 2FA announcement applies to SSH access. The public key you use is already 2FA enabled, in a sense (the key is what you have, the password to unlock it what you know).
This applies to logging in to the GitHub Web application.
This applies to logging in to the GitHub Web application.
Why should someone be using a password manager? Generating needlessly complex, unique passwords for each service seems like a good way to lock yourself out of your own accounts in an emergency.
Laptop or phone stolen? No access to your own devices? Oops guess you can't login to anything.
Laptop or phone stolen? No access to your own devices? Oops guess you can't login to anything.
That is a scenario that is a lot less likely than some service having losing control over your password. If you are concerned about it, you can always write down the password into a physical notebook.
What about trying to login on someone elses device? Or your system crashing/corrupting?
The scenarios in which you are unable to use your password manager are far more likely than you're making it seem.
The scenarios in which you are unable to use your password manager are far more likely than you're making it seem.
because it makes your passwords significantly less likely to be guessed
I don't know of a single competent service that allows you to just guess passwords more than a few times.
The biggest problem is re-using passwords. Remember when that LinkedIn password database with plaintext/md5 (easily brute-forced) was leaked a few years back? And who knows what's going on with Heroku right now. There's been dozens, hundreds, thousands of leaks like this, from well known sites like LinkedIn to that small independent webshop where you ordered something a few years ago. And for at least some people those credentials that worked on LinkedIn may also work on GitHub.
Having a unique password per service solves that particular issue. But you're right that there's a "price" in that losing access to your passwords would leave you screwed. I'd strongly recommend making sure you at least memorize your email password, as well as backing it up in several places.
Having a unique password per service solves that particular issue. But you're right that there's a "price" in that losing access to your passwords would leave you screwed. I'd strongly recommend making sure you at least memorize your email password, as well as backing it up in several places.
I wish they'd let me stay logged in longer. I use about 9 machines. On each machine I use 2-3 browsers. On some of those browsers I have several profiles. GitHub logs me out if I haven't used it in about 2 weeks. The result is I have to login with 2FA almost daily. it's super annoying
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.
My bank's website is even worse. They won't let me log in if I had the landing page open for 10 minutes before logging in until I refresh...
Wonder whether it's related to attack on Heroku.
PSA: you should ALWAYS download the recovery codes when you enable 2FA.
Reading a lot of "phone broken; locked out of account" comments here and I don't know whether they understand that local one-time only recovery codes should be downloaded and stored safely (maybe even printed and stored in a safe, I do not know). If you lose access to your 2FA device, use the "recovery code" option and use one of your recovery codes to unlock your account.
Reading a lot of "phone broken; locked out of account" comments here and I don't know whether they understand that local one-time only recovery codes should be downloaded and stored safely (maybe even printed and stored in a safe, I do not know). If you lose access to your 2FA device, use the "recovery code" option and use one of your recovery codes to unlock your account.
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.
"they had no idea what I was talking about and clearly had no ability to actually do anything about the 2FA issue"
What are they supposed to do to fix your issue without compromising their security model?
What you describe sounds like 2FA working like it's supposed to.
What are they supposed to do to fix your issue without compromising their security model?
What you describe sounds like 2FA working like it's supposed to.
Disconnect the phone number from that old account and allow him to create a new account using the phone number.
If I cancel my phone service, and someone else later ends up with my phone number, does it make sense that that person can never use Uber with their new phone?
Phone numbers are less transitory than street addresses, but much more so than email addresses. You should expect some amount of re-use, and need to be able to handle that situation.
If I cancel my phone service, and someone else later ends up with my phone number, does it make sense that that person can never use Uber with their new phone?
Phone numbers are less transitory than street addresses, but much more so than email addresses. You should expect some amount of re-use, and need to be able to handle that situation.
Their security model locks users out.
I nearly lost all my passwords with LastPass when something similar happened to me.
Is grandma supposed to file her 128 character recovery code in a safe vault when she just wants to get from the airport?
Stop blaming users for them not adapting to terrible authentication experience.
I nearly lost all my passwords with LastPass when something similar happened to me.
Is grandma supposed to file her 128 character recovery code in a safe vault when she just wants to get from the airport?
Stop blaming users for them not adapting to terrible authentication experience.
I'd be interested in hearing about a better model.
To me they're all terrible in one way or another.
To me they're all terrible in one way or another.
If the security is this important then recovery should involve AI facial recognition with human fallback to unlock a device.
Or else submitting a passport / drivers license to force unlock.
We have global identity systems. Why not use them?
Or else submitting a passport / drivers license to force unlock.
We have global identity systems. Why not use them?
Most companies offer manual processes to get round failed 2FA - for example, provide copies of ID, a video chat to confirm, security questions about account details (eg last trips you took), etc. I've had to do this for a couple of services where the process was quite onerous, but that's the point.
Doesn't help if you lose the keys and you're the only one that held them. This happened to me with an SSD that I took out of an old laptop, without realising that But locker stored its key on a chip in the laptop. I didn't even know that I had bitlocker enabled.
But Uber shouldn't have your trip details behind end to end encryption, so they should be able to unlock it.
Doesn't help if you lose the keys and you're the only one that held them. This happened to me with an SSD that I took out of an old laptop, without realising that But locker stored its key on a chip in the laptop. I didn't even know that I had bitlocker enabled.
But Uber shouldn't have your trip details behind end to end encryption, so they should be able to unlock it.
ID can be easily faked.
Security questions are often shared between services, so someone who's hacked any of the other services could get the answers to these same security questions and then use them to bypass 2FA.
Security questions are often shared between services, so someone who's hacked any of the other services could get the answers to these same security questions and then use them to bypass 2FA.
OK, replace "Uber" with your power company. You can't log into your account to update your expired credit card. Are they going to turn off your electricity because you dumb dumb didn't save your backup codes!
No of course not. They're going to help you out. Because we live in the real world where people make mistakes.
No of course not. They're going to help you out. Because we live in the real world where people make mistakes.
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).
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).
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.
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.
Besides, where do you store your 2FA backup codes? At home?? Where they could be stolen without your knowledge? Most people’s homes are less safe than their online life.
I would be more concerned about fire or natural disaster.
If your house catches on fire while you're asleep, there's decent odds both your phone and any printed codes are gone.
If your house catches on fire while you're asleep, there's decent odds both your phone and any printed codes are gone.
With 2FA someone can break into your home, find your 2FA backup codes, defeat your password (e.g. by finding it in a leak) and they're in. If they are targeting you from your online life they need to first find out where you live and travel there.
Without 2FA someone can defeat your password and they're in.
Without 2FA someone can defeat your password and they're in.
The historic solution is in a safety deposit box at a bank. If you're talking about things like crypto cold wallets which might be extremely valuable, why risk leaving it at home? The cost for small items like documents tends to be reasonable. Good practice for things like ownership deeds and wills.
I don't think the average home thief would know what to do with a printout of your 2FA recovery code especially if it's buried in other paperwork. The real risk is loss from negligence or natural disaster.
I don't think the average home thief would know what to do with a printout of your 2FA recovery code especially if it's buried in other paperwork. The real risk is loss from negligence or natural disaster.
Maybe a safe or cameras would be useful for when you're not home.
I sometimes leave my laptop on with motion started: https://motion-project.github.io/
You could store them encrypted with a passphrase that only you know, so even if they're stolen they would be useless without your passphrase.
You could also encode them in DNA nucleotides and use CRISPR to modify your own DNA with your GitHub codes. /s
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?
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?
The recovery key is different because it's "locked in a safe" and used rarely, if ever, instead of being used constantly.
But.. is passwords being used a common way for them to leak? I've never heard of this before but I'm no expert. Isn't the threat model either company databases being (badly hashed and) leaked, or password managers being hacked wholesale?
I mean where am I supposed to store the recovery key if not in my password manager? My dropbox surely isn't better encrypted than my bitwarden. I work with the assumption that my password manager is the least insecure piece of data storage I use.
I really don't get it. How isn't 2FA just security theater if we're all supposed to store the recovery keys "somewhere safe"? Can we really expect people to deal with recovery keys in a more responsible way than they do with passwords?
I mean where am I supposed to store the recovery key if not in my password manager? My dropbox surely isn't better encrypted than my bitwarden. I work with the assumption that my password manager is the least insecure piece of data storage I use.
I really don't get it. How isn't 2FA just security theater if we're all supposed to store the recovery keys "somewhere safe"? Can we really expect people to deal with recovery keys in a more responsible way than they do with passwords?
The best-case ordinary person is going to store them in "<user name>/My Documents/Security Keys/keys.txt".
The average-case person is going to ignore the generated keys because they are deluged with nonsense every day and can't filter out what is important anymore. Lots of people will get locked out of accounts before they learn that there is now yet another unwanted tech bureaucratic layer to take seriously.
I'm guessing in 5 years it will be normal to set up security questions for 2fa recovery keys. Or we'll add another 2fa for 2fa key recovery. The adding of layers will continue until we are all "secure" and we'll all have to ask for our misplaced keys from the NSA.
The average-case person is going to ignore the generated keys because they are deluged with nonsense every day and can't filter out what is important anymore. Lots of people will get locked out of accounts before they learn that there is now yet another unwanted tech bureaucratic layer to take seriously.
I'm guessing in 5 years it will be normal to set up security questions for 2fa recovery keys. Or we'll add another 2fa for 2fa key recovery. The adding of layers will continue until we are all "secure" and we'll all have to ask for our misplaced keys from the NSA.
>I mean where am I supposed to store the recovery key if not in my password manager?
My password manager (keepassxc) supports multiple databases. I store all TOTP recovery codes in a separate database (and with a different unlocking password) from the one that has regular passwords and the TOTP secrets.
All my databases are backed up on someone-else's-computer, but I only keep the regular-passwords-and-TOTP-secrets database synced to my devices.
My password manager (keepassxc) supports multiple databases. I store all TOTP recovery codes in a separate database (and with a different unlocking password) from the one that has regular passwords and the TOTP secrets.
All my databases are backed up on someone-else's-computer, but I only keep the regular-passwords-and-TOTP-secrets database synced to my devices.
I think "ideally" you print out the codes and physically secure them somewhere, so the risk isn't high. Recovery codes aren't about safety from being hacked, they're about mitigating the risk of you losing your 2FA code device.
In practice, 2FA is just another password anyway. What it really helps with is password reuse.
In practice, 2FA is just another password anyway. What it really helps with is password reuse.
But what about on the server side? We generally know about passwords being salted and hashed. How are these recovery keys stored, regenerated etc? (I suppose they are also salted and hashed, but they are shorter and potentially easier to crack than good passwords, given a breach, no? Or just one longer, tougher recoveryKeyGenKey need be salted and hashed.)
This is of course implementation dependent, but ideally a recovery key is single use. You should also be notified by email or some other channel that the recovery key was used. Then you are immediately aware if this use was unauthorized and you can take appropriate action. This type of response is not possible for unauthorized password use.
you can get notifications for logins from a new device. isn't that just as useful?
I think there's at least a couple ways these are different:
1. It's easy to start ignoring such notifications if you regularly log in to new devices (or if logins expire). I don't think this is true to the same degree with notifications of recovery code usage.
2. Devices can potentially be spoofed.
1. It's easy to start ignoring such notifications if you regularly log in to new devices (or if logins expire). I don't think this is true to the same degree with notifications of recovery code usage.
2. Devices can potentially be spoofed.
Recovery codes are generated by the server, so:
• there's no temptation for the user to use them on another website, where they could leak
• the server can ensure they are high-entropy (although AFAICS GitHub's recovery codes are only 40-bit…)
Moreover, if someone takes over your e-mail account, they can reset your password; but they can't reset the recovery codes.
• there's no temptation for the user to use them on another website, where they could leak
• the server can ensure they are high-entropy (although AFAICS GitHub's recovery codes are only 40-bit…)
Moreover, if someone takes over your e-mail account, they can reset your password; but they can't reset the recovery codes.
If this is all though, then couldn't we just use username+password auth but have the server generate the password? Why at the phone to the loop at all?
Are you saying that iPhone-maker Apple and Android-maker Google (and TPM-mandator Microsoft) might not be able to imagine a future where the whole world isn't dependent on them for identity?
No, I am not suggesting that 2FA is a secret ploy by BigCos to make them needlessly important. It's perfectly possible to log into services without using your Google/Apple/Microsoft identity, even if they insist on 2FA. Use the email and SMS, Luke!
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 :)
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 :)
isn't it just better to use an app such as 1Password that can keep all your one-time passwords?
Then if the password manager is compromised, the second factor wouldn't add any protection over just a password.
Then again, people that use password managers at all usually have stronger passwords and less password reuse, so it can be an acceptable tradeoff.
Then again, people that use password managers at all usually have stronger passwords and less password reuse, so it can be an acceptable tradeoff.
In my case it wouldn't anyway. Almost all of my 2FA is tied to my password manager as well. I am sure I am not alone in this. It is kind of scary to think about though.
I do the same but, for me, the threat of my password manager being compromised is much much smaller than the threat me not enabling 2FA out of laziness or the concern I might lose my 2FA codes. I keep my main email codes out of the password vault and that is enough to calm my nerves.
Not everyone has the same risk profile/tolerance, but I just wanted to say that I don't think anyone should feel bad about doing the best they can, even if that stops short of the absolute best.
Not everyone has the same risk profile/tolerance, but I just wanted to say that I don't think anyone should feel bad about doing the best they can, even if that stops short of the absolute best.
Aye, but it assumes the company isn't keep the password in plain text.
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.
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 feel like with the recent hackings done by Lapsus, it shows that 2FA can actually make it easier to break into a system. Since they first break into telecom companies, they can then sim swap and reset peoples passwords.
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.
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?”
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?”
If an attacker can get a SIM for your number, SMS 2fa is useless. They will get the second factor by text message just as you would.
They still need your password. The SMS alone is insufficient. Supporting SMS as a second factor (whether primary or backup) is perfectly adequate for almost everyone’s threat model, and generally far superior to not supporting it as regards avoiding account lockout. (That’s Fastmail’s position, which I thoroughly agree with.)
I agree it's probably better than nothing for many people.
It's still pretty much the worst form of 2fa there is, and not nearly as secure as people assume.
It's still pretty much the worst form of 2fa there is, and not nearly as secure as people assume.
It's not useless. It forces the attacker to expand all the effort to get a SIM for your number. While certainly possible, it's not that easy.
I said it's useless if an attacker can get access to a SIM (or hack the SS7 protocol, or whatever).
Clearly it's an extra bar for an attacker, no disagreement there.
Clearly it's an extra bar for an attacker, no disagreement there.
But they need your password first. So you’re not in a worse position than if you didn’t have 2FA. Parent was implying 2FA made it worse.
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.
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.
That's because SMS is not 2FA. Proper 2FA implementation should require FIDO, TOTP, etc. and not even permit SMS as a valid method.
Nitpicking, but it absolutely is 2FA. Two factors for authentication. Password (something you know) and phone (something you have).
It's not good 2fa, but it is 2fa.
It's not good 2fa, but it is 2fa.
SMS should not be considered a 2fa, TOTP or a youbikey is the minimum that you should be able to advertise as 2fa.
Well, it seems like a good time to start migrating away from GitHub. When they can't be bothered to remove malware accounts like the node-ipc dudebro, but then claim they need a phone number from me to keep logged in for "security" ... I'll just leave. It's been a good run, I've had the account over 10 years, but I recently discovered Gitea is API compatible with GitHub. I can just make that my drop in replacement. I can even allow federated login with Keycloak + Gitea OIDC for anyone on GitHub who wants to log in on it and collaborate.
Thanks for all the fish.
Thanks for all the fish.
Can anyone ELI5?
It seems that I will requires either SMS, a mobile app, or USB dongle. I'm not happy about any of these options. I'm not going to give away my phone number, I don't have a smartphone (I have a Nexus from 2012 though), and I don't want to fork out on dongles.
Someone mentioned that keepassx being able to do it, but I'm a bit hazy on that.
I've registered for a gitlab account just now, and I'll be messing around with that for awhile to see if I like it. If it proves tolerable, I'll probably be yanking the plug on github.
It seems that I will requires either SMS, a mobile app, or USB dongle. I'm not happy about any of these options. I'm not going to give away my phone number, I don't have a smartphone (I have a Nexus from 2012 though), and I don't want to fork out on dongles.
Someone mentioned that keepassx being able to do it, but I'm a bit hazy on that.
I've registered for a gitlab account just now, and I'll be messing around with that for awhile to see if I like it. If it proves tolerable, I'll probably be yanking the plug on github.
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, my understanding so far is that Github (or anyone, in general) will provide a private key consisting of 24 alphanum chars. Github also has a copy of the key.
To authenticate, a password is generated based on the private key, which acts as a seed. That seed is combined with a timestamp in order to generate a password, which has an expiry time of about 1 minute. The algorithm that generates the password is a standard one, so once you know the algorithm, you can generate valid passwords.
Linux provides "oathtool", which is suitable for such a purpose.
Is my understanding correct on this?
To authenticate, a password is generated based on the private key, which acts as a seed. That seed is combined with a timestamp in order to generate a password, which has an expiry time of about 1 minute. The algorithm that generates the password is a standard one, so once you know the algorithm, you can generate valid passwords.
Linux provides "oathtool", which is suitable for such a purpose.
Is my understanding correct on this?
> private key
It's a "shared secret". ("private key" implies only one party knows it.)
> 24 alphanum chars
Hmm, https://datatracker.ietf.org/doc/html/rfc4226#section-4 says the key "MUST be at least 128 bits", meaning at least 26 (base-32) chars.
My current TOTP secret (generated in 2018) for GitHub is only 20 chars. :-/
> Is my understanding correct on this?
Yes.
It's a "shared secret". ("private key" implies only one party knows it.)
> 24 alphanum chars
Hmm, https://datatracker.ietf.org/doc/html/rfc4226#section-4 says the key "MUST be at least 128 bits", meaning at least 26 (base-32) chars.
My current TOTP secret (generated in 2018) for GitHub is only 20 chars. :-/
> Is my understanding correct on this?
Yes.
So, what happened to openid? I take it that it's no longer a thing.
Except it's not actually 2FA if all it takes is an ssh key to push. That's only one factor. Doesn't address the threat model of compromised developer machine.
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.
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
1. https://github.com/drduh/YubiKey-Guide
The blog post only mentions Mobile Push and WebAuthN. Is Github deprecating TOTP 2FA?
I also can't believe how many people are complaining about requiring 2FA. I have 2FA enabled for every single service that gives you the option. Backup Codes live in my password manager, and I have multiple yubikeys that I enroll whenever it's an option. It's been 10 years since I started doing this, and I've never been locked out.
I also can't believe how many people are complaining about requiring 2FA. I have 2FA enabled for every single service that gives you the option. Backup Codes live in my password manager, and I have multiple yubikeys that I enroll whenever it's an option. It's been 10 years since I started doing this, and I've never been locked out.
425% cost increase to enable SSO on Github. Just saying.
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!
Having a central way of managing who has access to a repo is an enterprise feature? I call bullshit on this.
So ridiculous. Really hurts for smaller startups.
If you're small then the benefits of SSO aren't really there anyway. When you're a team of 10, what benefit is SSO really giving?
I work in a small company and we have to have SSO for compliance reasons (SOC II, HIPAA, NIST, etc)
It’s dumb but without it trying to tick all the compliance boxes is much more annoying.
It’s dumb but without it trying to tick all the compliance boxes is much more annoying.
You go through a review, and somebody asks who this guy xxx123 is that made this change, and somebody vaguely recalls it is some consultant that for some reason still have access to everything but quit two years ago. Love those meetings.
Unfortunately this is not true when you're trying to undergo a SOC 2 audit.
First, there is no requirement by SOC2 that says you "must use SSO for all applications". SOC2 talks about "logical access controls". For a team of 10, you would simply have a policy that states "any time a new developer comes on, they have to use MFA to access GitHub and this is enforced because we check the box in GH, blah blah" and "any time a developer leaves the company, we revoke all access, blah blah".
Also, if you're going to spend $20k+ on SOC2 because your clients require it, then spending the $20k on GitHub shouldn't be a problem because your clients should be paying for it (i.e. your ACV should be high enough to cover these things).
Also, if you're going to spend $20k+ on SOC2 because your clients require it, then spending the $20k on GitHub shouldn't be a problem because your clients should be paying for it (i.e. your ACV should be high enough to cover these things).
Yes, but SSO makes writing those policies (across all apps) much simpler. I think it's too bad that SSO is so heavily taxed, because it's quite an elegant way to solve account provisioning.
Interesting site: https://sso.tax/
Interesting site: https://sso.tax/
Understood.
> I think it's too bad that SSO is so heavily taxed
Honestly, most software (especially SaaS) is underpriced for the value it creates. SSO is just an easy way to bump clients into the "real" pricing of the software while still letting them try most/all of the core features.
> I think it's too bad that SSO is so heavily taxed
Honestly, most software (especially SaaS) is underpriced for the value it creates. SSO is just an easy way to bump clients into the "real" pricing of the software while still letting them try most/all of the core features.
[deleted]
That’s my cue … to exit GitHub … and Google mail as well
I don’t have a phone number (that I am willing to fork over) so there’s that.
Welcome me, GITLAB!
I don’t have a phone number (that I am willing to fork over) so there’s that.
Welcome me, GITLAB!
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.
This is a Microsoft-owned subsidiary. They too will fall in line of choking you for a phone number.
Don't they already offer a 2FA option now? Why not just let people use it who want to, and leave everyone else alone?
I am an adult. If I want to sacrifice some security in the name of convenience, I should have that option. All this is doing, is pissing me off, and giving me one more reason to move to another platform.
I am an adult. If I want to sacrifice some security in the name of convenience, I should have that option. All this is doing, is pissing me off, and giving me one more reason to move to another platform.
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).
The organizational control is already the case :) I had to set it up when I was added to my work's GitHub org.
I wish my PGP key could be used as a root identity for my 2FA keys :/
I wonder what this will mean for the relatively easy onramp for kids through Micro:bit and other tools? Maybe kids aren't supposed to directly access GitHub?
They do not give a single argument to show why they need to require 2FA, the same way they did not provide an argument for removing git password login. The more they will annoy users the more it will create space for a new service to compete with Github. Thanks Microsoft.
The biggest problem with Github in my opinion, is that personal accounts are usually the same as the one we use in the company we work for. So we are mixing personal and professional security
The biggest problem with Github in my opinion, is that personal accounts are usually the same as the one we use in the company we work for. So we are mixing personal and professional security
I think the argument has already been made for 2FA often enough though. So they probably just assumed everyone had heard it (wrongly perhaps?).
Years ago when I setup a GitHub organization for our research collaborators, I initially mandates 2FA. But someone protested and brought up a point I’ve never considered—many of them needs to be on-site, like the Chile desert or South Pole, which has extreme environments. One collaborator briefed people going to Chile saying “if you love your device, don’t bring it to the site in Chile.” It is very high in altitude that can causes spinning HDD to fail. And the fine dust there getting into your device is no fun.
So the consequence is that that don’t bring their phone to the site. They would leave it somewhere else before going up to the site. Needless to say that this 2FA requirement is a huge pain to them. There’s no second device for them. And even if someone could have a hardware key, those can becomes broken due to the reason above, and they don’t want that single point of failure to cause them trouble.
So those people would basically try to defeat 2FA because of this. Eg our university requires 2FA to login to their network. They come up with a method to get the secret of the HOTP (from Duo, which is much less popular than TOTP that Eg Google use.)
I also made a suggestion for those people to use SMS for 2FA and use Google Voice for the phone no. Again, another way to make 2FA works on a single device.
P.S. needless to say on site they have servers and computers to collect data and analyze them. So they need to log in even if they don’t have a phone with them.
So the consequence is that that don’t bring their phone to the site. They would leave it somewhere else before going up to the site. Needless to say that this 2FA requirement is a huge pain to them. There’s no second device for them. And even if someone could have a hardware key, those can becomes broken due to the reason above, and they don’t want that single point of failure to cause them trouble.
So those people would basically try to defeat 2FA because of this. Eg our university requires 2FA to login to their network. They come up with a method to get the secret of the HOTP (from Duo, which is much less popular than TOTP that Eg Google use.)
I also made a suggestion for those people to use SMS for 2FA and use Google Voice for the phone no. Again, another way to make 2FA works on a single device.
P.S. needless to say on site they have servers and computers to collect data and analyze them. So they need to log in even if they don’t have a phone with them.
It's not 2 factor, it's ultimately 3rd party. I'll leave before I enable it.
I disagree with requiring it in general.
As soon as you admin repos, sure.
Meanwhile Spotify and Hulu still dont provide it as an option...
why do you need 2fa for either of those?
Do content creators have ask area to manage whatever songs they upload to Spotify? I actually don’t know! But if they do, I could see the need for 2FA on the content creator side.
Do they have an option for no SMS, just MFA?
By 2030 all websites will require 2FA, SSL Client Checks, Real ID Verified and a blood pin prick.
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
[0] https://art.tools.ietf.org/id/draft-fedorkow-rats-network-de...
[1] https://c.mi.com/thread-3882246-1-0.html
You don't need a phone, or great deals, to interact with a food place.
For now. Even before the pandemic, "delivery-only" restaurants were replacing brick-and-mortar ones:
https://www.forbes.com/sites/michelinemaynard/2017/03/28/as-...
https://www.forbes.com/sites/michelinemaynard/2017/03/28/as-...
Get rid of the stupid requirement for SMS or TOTP.
Allow me to commit career suicide with my counter argument. My laptop random shuts off at least once a day (the screen goes freeze, then goes pink, it's an M1 mac if that helps). My phone's screen is mostly crunched glass shards, and when I charge it, the correct voltage doesn't go through. I think the problem is the outlets where I'm living?
Anyway, my own devices are the biggest risk in my threat model. Both my laptop (where I'd store the backup codes for GH MFA) and my phone (normal MFA authenticator app) turning into bricks is a WAY higher risk than someone stealing my Github password.
I'm not even a part of any orgs, no maintained packages (not on the account I use now, anyways). So I could store my backup codes on the cloud, but Google is getting fussier every day about 'lack of backup device' or whatever.
I could use a one time pad (and just memorize it), and store the encrypted backup codes on some kind of decentralized, permanent db. So a blockchain. But that costs money, and this is basically a venial irrelevant problem that I'm only complaining about to be a naysayer on this thread. So let's look for a free solution...
Well, what about... free anonymous blogging solutions! I can publish it to a bunch of these. I can use memorable usernames. Now, I just have to remember the platform(s, plural, cause one platform is still risky, could get the account banned or something by doing this, so I'll want to use all the big ones, reddit, twitter, and so on), the usernames (which will all be the same, to accommodate memorization lol), the 2fa backup code one time pad, and of course the password itself. But I could use the password as the one time pad to lighten the load. And the username could be really easily made memorable.
Yes! How easy is that? Okay, I'm going to try it out. If my approach is flawed, feel free to steal my GH account (as you can probably ascertain, it's a throwaway GH account, which is the only reason I'd be annoyed at having to 2FA for it).
I'll report back to this threat and leave a response to myself once I have this set up, in case anyone else is curious.
Anyway, my own devices are the biggest risk in my threat model. Both my laptop (where I'd store the backup codes for GH MFA) and my phone (normal MFA authenticator app) turning into bricks is a WAY higher risk than someone stealing my Github password.
I'm not even a part of any orgs, no maintained packages (not on the account I use now, anyways). So I could store my backup codes on the cloud, but Google is getting fussier every day about 'lack of backup device' or whatever.
I could use a one time pad (and just memorize it), and store the encrypted backup codes on some kind of decentralized, permanent db. So a blockchain. But that costs money, and this is basically a venial irrelevant problem that I'm only complaining about to be a naysayer on this thread. So let's look for a free solution...
Well, what about... free anonymous blogging solutions! I can publish it to a bunch of these. I can use memorable usernames. Now, I just have to remember the platform(s, plural, cause one platform is still risky, could get the account banned or something by doing this, so I'll want to use all the big ones, reddit, twitter, and so on), the usernames (which will all be the same, to accommodate memorization lol), the 2fa backup code one time pad, and of course the password itself. But I could use the password as the one time pad to lighten the load. And the username could be really easily made memorable.
Yes! How easy is that? Okay, I'm going to try it out. If my approach is flawed, feel free to steal my GH account (as you can probably ascertain, it's a throwaway GH account, which is the only reason I'd be annoyed at having to 2FA for it).
I'll report back to this threat and leave a response to myself once I have this set up, in case anyone else is curious.
Why not just ... print out or write down the backup codes?
1. Don't own a printer
2. Don't want my hand to cramp
3. I'm being silly, everyone should use MFA
2. Don't want my hand to cramp
3. I'm being silly, everyone should use MFA
Email it to your wife or someone you trust. It will just sit in their archived folder until you have an emergency
Since the backups are encrypted with my one time pad, I don't need a ton of trust, just reliability that they'll send me the encrypted codes. I already have them on the subreddit I made in my other comment, buuut, it's always nice to have another layer of redundancy, right?
Hey, what's your email address?
Hey, what's your email address?
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
https://www.reddit.com/r/encrypted_gb_codes/comments/uj1fll/...
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))
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.
When I read this announcement I was happy because this means 2fa is getting even more known,.accepted and used.
[deleted]
If for 2FA they mean a cellphone for the "offband" communication of a code, I am out.
They don’t. Reading the article would have answered that question.
It's an article concerning GitHub and security --- so you can rest assured nobody will read the article and they will instead flail wildly about how this is Basically George Orwell Doing 1984.
I don't know about you, but I don't have time for reading everything gets published on the web – this is why I framed my sentence in the hypothetical. Reading my comment would have clarified my own point of view.
When I think of what the "most important" account is to me, my Github page is pretty damn close to the top. Mine is currently 2FA with an automated script that will scan my Github and back everything up to GitLab (at least the "important" projects), which is also 2FA'd.
Insane setup to protect data in one account but if I loose access it would be beyond a bad day for me.