I have a really hard time understanding their reticence to use a better security measure. To me, this is the equivalent of saying "I will absolutely not use a symbol in my password". As for this...
I have a really hard time understanding their reticence to use a better security measure. To me, this is the equivalent of saying "I will absolutely not use a symbol in my password".
As for this part: "If I cannot opt out of 2FA, please point me to information on how to migrate my source code off of GitHub to another provider, such as GitLab, BitBucket, or similar." It is an empty threat. You could just google this, they just wanted to add that to make it sound like a threat.
I use ssh-keygen to generate public/private keys for authenticating against GitHub. I don't see any reason to give them my phone number or install yet another piece of software on my computer. Why...
I use ssh-keygen to generate public/private keys for authenticating against GitHub. I don't see any reason to give them my phone number or install yet another piece of software on my computer. Why isn't using ssh-keygen sufficient security?
Compromised how? Even if github leaks password hashes you'll be fine with your randomly generated 20 symbols long password from password manager of choice.
Compromised how? Even if github leaks password hashes you'll be fine with your randomly generated 20 symbols long password from password manager of choice.
Of all the apps, a good TOTP app is one well worth having. You can also use Passkey functionality on your iOS/Android phone and skip the app altogether, though Firefox doesn’t currently support it.
install yet another piece of software on my computer
Of all the apps, a good TOTP app is one well worth having. You can also use Passkey functionality on your iOS/Android phone and skip the app altogether, though Firefox doesn’t currently support it.
Afaik a bunch of scientific institutions (including a data center on my university campus) were infiltrated (for data exfiltration and bitcoin mining in their high performance computation center)...
Afaik a bunch of scientific institutions (including a data center on my university campus) were infiltrated (for data exfiltration and bitcoin mining in their high performance computation center) a year or two ago, because some guy with access to the data center didn't follow policy and thought leaving their ssh key lying around on their laptop unencrypted (aka without a passphrase) wasn't to bad.
According to this, git command line access over SSH isn't affected by MFA. It's just when you need to log into your account via the browser. So daily operations like git clone/push/pull won't...
According to this, git command line access over SSH isn't affected by MFA. It's just when you need to log into your account via the browser. So daily operations like git clone/push/pull won't require MFA if you configure your remote to use SSH. But if you wanted to modify your key / add a new key, you would need MFA to do so.
This is why developers that behave this way and don't care about security at all are not liked by the security and systems teams at companies... whether these are 'rockstar' or 'primmadonna'...
This is why developers that behave this way and don't care about security at all are not liked by the security and systems teams at companies... whether these are 'rockstar' or 'primmadonna' developers or not, this doesn't excuse that behaviour and childishness.
This seems overly performative to me. I don’t think GitHub wronged you and can’t understand the intense reaction. I don’t mind someone moving their code to a different host. Please host where you...
This seems overly performative to me. I don’t think GitHub wronged you and can’t understand the intense reaction. I don’t mind someone moving their code to a different host. Please host where you most enjoy the experience. But why involve this website in the process? You’re not here for our input.
I dont think this is totally fair. If you agree, it's fine to comment that you agree, but if you disagree and post about it it's performative? Or alternately, if you say you are going to do...
I dont think this is totally fair. If you agree, it's fine to comment that you agree, but if you disagree and post about it it's performative?
Or alternately, if you say you are going to do something it's a bluff, but if you actually did it it's performative?
What's the valid way to express an opinion that isnt performative? I agree everyone who is upset could just silently leave github and not talk about it, but its a forum, you're supposed to talk about stuff.
By saying "empty threat" I did not mean "they won't do it". What I meant was "they are saying it to get attention". If it was simply "if you do this, I will leave" then that's fine and people...
By saying "empty threat" I did not mean "they won't do it". What I meant was "they are saying it to get attention". If it was simply "if you do this, I will leave" then that's fine and people generally don't care if a small subset of users leave (I bet it's expected and worthwhile to improve the security), but I instead it was "do this or show me how to get off the platform". That is one of the easiest thing to google and I don't believe for a second that these people can't figure out how to google exactly that.
It was all performative to get attention, probably due to frustration on the user's part. I am not saying it was malicious, but it was definitely attention seeking behavior, maybe to attempt to get this reversed.
Edit: I just realized you are the same person as the linked post. This makes it a lot more personal than talking in the abstract about the post of a random person. I will leave this up because I stand behind it, but I don't mean to attack you directly.
I don't know about highly technical users, but 2FA for me is like saying "You will eventually lose access to your account and there's nothing you can do about it". I've seen it happen multiple...
I don't know about highly technical users, but 2FA for me is like saying "You will eventually lose access to your account and there's nothing you can do about it". I've seen it happen multiple times. You know what have I never seen in real life? A third party stealing someone's account. From my layman's perspective, 2FA is a greater risk than hackers.
Wait, really? You've actually never heard of someone obtaining someone else's credentials and using them to take over their account? Or am I not understanding something?
You know what have I never seen? A third party stealing someone's account.
Wait, really? You've actually never heard of someone obtaining someone else's credentials and using them to take over their account? Or am I not understanding something?
I've literally never seen it happen with anyone in real life. But I've seen multiple accounts lost to 2FA and other "ultra-secure" mechanisms. 2FA scares me to death.
I've literally never seen it happen with anyone in real life. But I've seen multiple accounts lost to 2FA and other "ultra-secure" mechanisms.
I don't know anyone who has lost a 2FA if you want counter-anecdotal experience. There are tools like Authy that can backup your 2FA across multiple devices.
I don't know anyone who has lost a 2FA if you want counter-anecdotal experience. There are tools like Authy that can backup your 2FA across multiple devices.
It's multi factor security, not iron proof security. If someone breaks into your authy, they still need to break your password. If someone breaks your password, yet still need your authy. It...
It's multi factor security, not iron proof security. If someone breaks into your authy, they still need to break your password. If someone breaks your password, yet still need your authy. It greatly reduces the chance that a single provider getting hacked will lead to account hijacking.
You need to be thinking more broadly, not just of a targeted attack on your machine. That's typically the least likely attack to experience for the average person.
You need to be thinking more broadly, not just of a targeted attack on your machine. That's typically the least likely attack to experience for the average person.
The advantage of MFA with rotating codes vs. SSH keys is that most websites don't let you paste or feed in an SSH key. It's an ease of use and accessibility issue. I don't think our current...
The advantage of MFA with rotating codes vs. SSH keys is that most websites don't let you paste or feed in an SSH key. It's an ease of use and accessibility issue. I don't think our current iteration of MFA is the final state of what it should be, though.
Have you tried to onboard brand new software engineers recently? It is significantly easier to get them to use and understand Authy or Google Authenticator compared to SSH keys. Additionally they...
Have you tried to onboard brand new software engineers recently? It is significantly easier to get them to use and understand Authy or Google Authenticator compared to SSH keys. Additionally they probably already need these applications for other company resources / SSO.
A big part of that issue is the general lack of assistance with ssh keys. Documentation and instruction are either whitepaper level or "just do it lol". Services almost never specify what...
A big part of that issue is the general lack of assistance with ssh keys. Documentation and instruction are either whitepaper level or "just do it lol". Services almost never specify what parameters they require for ssh keys, but they definitely do have requirements that you need to nail or you get a basic "something's wrong" error. And Windows likes to pretend ssh doesn't even exist, except when it does and you better do it exactly as Microsoft wants but doesn't explain or you'll be fighting gremlins constantly.
Essentially, everyone does a shit job of handling ssh keys, so no wonder people struggle to learn/use them. I agree they are great but the tooling and UX could be so so so greatly improved.
It's pretty recoverable through some identity verification checks, and most services provide recovery codes that can be safely stored in case one loses access to their 2FA device. It's been a...
It's pretty recoverable through some identity verification checks, and most services provide recovery codes that can be safely stored in case one loses access to their 2FA device. It's been a failsafe for nearly as long as 2FA has been around. I've lost entire 2FA devices that rendered me unable to access many of my accounts, and I got access back within an hour or two.
I have to imagine that most cases of people losing access to an account for any lengthy period of time due to 2FA have some degree of negligence involved or something went very wrong in the process at some point.
It is unfortunate that real people don't really know or care about theory. Keys and locks are simple and intuitive metaphor. My father, mother, and grandparents all understand it, no education...
It is unfortunate that real people don't really know or care about theory.
Keys and locks are simple and intuitive metaphor. My father, mother, and grandparents all understand it, no education required.
A lot of the times, 2FA is only really perceived as something more than a nuisance when you lose your smartphone, only to realize that your password is now completely useless.
With all due respect, but it's incredibly out of touch to think grandma will keep a dozen recovery codes in her purse. Or even know what recovery codes are.
Programmers are highly capable at programming, but are seemingly not as capable of anticipating the needs of less technical users.
Sure. 2FA, or even something more complicated, absolutely makes sense for GitHub specifically. I just get ranty about 2FA. You can mark all of that as off topic.
Sure. 2FA, or even something more complicated, absolutely makes sense for GitHub specifically.
I just get ranty about 2FA. You can mark all of that as off topic.
Oh no worries. I think it's on topic enough. I used to hate 2FA too, and I lost all my authenticators once when my phone broke. After that I invested some time in figuring out how to have them...
Oh no worries. I think it's on topic enough.
I used to hate 2FA too, and I lost all my authenticators once when my phone broke. After that I invested some time in figuring out how to have them backed up (I used the paid version of Authenticator Plus but Authy provides the same functionality for free), then later moved them all to my 1Password vault which I can access on all my devices (protected by a secret key and master password, which I have printed and locked away). 1P on my laptop locks itself after 1 minute of inactivity, and once it is unlocked it can just fill in 2FA codes for me quickly. It has made 2FA painless for me and I would recommend it.
However, yeah, Grandma isn't gonna do any of that. But if she really needed 2FA she could probably handle getting codes via SMS or email if someone explained it to her. I definitely support it being optional for most apps/sites.
Grandma lost her prepaid phone. Grandma does not own a computer. Grandma's email itself requires 2FA. Grandma is in a loop. Now grandma lost her accounts. Grandma can't message her doctor. Grandma...
Grandma lost her prepaid phone. Grandma does not own a computer. Grandma's email itself requires 2FA. Grandma is in a loop. Now grandma lost her accounts. Grandma can't message her doctor. Grandma is now dead.
I am on a bus to Cambodia.
Someone stole my phone while I was sleeping.
My email requires 2FA, I am hooped.
I can't access my plane tickets or other travel information.
I am a software engineer,
I am still in Cambodia, please send help.
That's why I keep a recovery code in a couple articles of clothing. Got some washer proof custom stickers made with a simple cipher to make it less obvious what it is.
That's why I keep a recovery code in a couple articles of clothing. Got some washer proof custom stickers made with a simple cipher to make it less obvious what it is.
I'm speaking about people that are capable and have put in the work to understand 2FA enough to actually use and apply it. I find it hard to believe it would lead to someone inevitably losing...
I'm speaking about people that are capable and have put in the work to understand 2FA enough to actually use and apply it. I find it hard to believe it would lead to someone inevitably losing their account when there's so many ways to recover an account should the 2FA device go missing. The recovery codes are just one method, most services seem to use email or phone verification instead as a backup which is a friendlier approach to many who aren't up to speed with tech.
And since this is GitHub, the assumption of technical competence among the userbase is reasonably a lot higher than most other services or tools. I'd hope that if grandma is slinging code to FOSS tools, she'd be capable of figuring out 2FA recovery codes.
Of course there will be people who simply can't grasp it and will have trouble but solving for them is another issue that has plagued technology as a concept forever, especially when it comes to security (where the inherent inconvenience means it meets more resistance than most other tech). At some point, it's about what's necessary to have a minimum level of security and everyone having to adapt to preserve overall integrity. It used to be that one alphabet-only password of 8 characters was enough, but that hasn't been the case in a long time.
Solving for the technologically illiterate is another issue entirely. In a casual way, there's always been the concept of helping family members and the like to protect their interests. Before computers, children helped parents modernize their banking and insurance setups, get their government paperwork in place, set up monthly payments for new bills and utilities, etc. Managing digital accounts isn't a step away from this. I'd hope that if someone is helping their parents or grandparents make necessary accounts with necessary security, they're also doing things like making their own backups of those recovery codes or account information when necessary.
I'm absolutely fine with mandating extra security (as if MFA isn't bare minimum) on a place that frequently hosts repositories referenced deep inside other programs that never get another thought...
I'm absolutely fine with mandating extra security (as if MFA isn't bare minimum) on a place that frequently hosts repositories referenced deep inside other programs that never get another thought and that is linked to as a generally safe downloading place for software. Protecting every link in that software distribution chain is important.
As a a slightly exasperated IT professional I also can't grasp any objection to MFA. Yes it's slightly inconvenient, but it is literally a bare minimum requirement to make sure your users are protected in a world of weak, reused passwords and incredibly skilled phishing attempts.
If you truly can't stand involving a physical phone in the process, there are open source MFA key programs you can install on whatever computer you're currently working on instead of a phone. If the goal is to be able to access the site from anywhere on public computers, get a portable token generator no bigger than a flash drive and throw it on your keychain.
The security world is moving to abandon passwords completely wherever possible for good reason, as bad actors continue to improve their methods you need another layer of protection on your accounts.
It's really more about people irritated about inconvenient or badly implemented security measures. One of the websites I go to cannot seem to figure out cookies and so I'm constantly needing to...
As a a slightly exasperated IT professional I also can't grasp any objection to MFA. Yes it's slightly inconvenient, but it is literally a bare minimum requirement to make sure your users are protected in a world of weak, reused passwords and incredibly skilled phishing attempts.
It's really more about people irritated about inconvenient or badly implemented security measures.
One of the websites I go to cannot seem to figure out cookies and so I'm constantly needing to log in, and their login form is so messed up that my password manager doesn't seem to want to work with it.
A lot of businesses implement MFA in the form of tokens sent via SMS. That's both invasive, since it requires your phone number, highly inconvenient, and unreliable since it will often reject or silently fail to work with VoIP numbers. Sometimes they send tokens to your email which is especially irritating since email is an inherantly unreliable service. I've had plenty of times where it took so long to get a token email that the token was already expired by the time it got to me. I've had even more times when I grew impatient waiting for one to get sent that I think it just isn't coming so I send out another request, and when I finally get the first token it doesn't work and attempting to use it has invalidated the second token as well.
Hardware based tokens are nice, but nobody owns them, and they have their own downfalls as well. Right now the best option for most is time-based one time password systems a la google authenticator. But even then it's not really convenient unless you're using a synced password manager so you're not glancing across screens and carefully trying to enter the token and submit it before the time limit.
SMS MFA is indeed bad, but it's also not what GitHub uses, at least not by default (you can either use Github's own mobile app or a dedicated MFA app like Google Authenticator). So it's incredibly...
A lot of businesses implement MFA in the form of tokens sent via SMS. That's both invasive, since it requires your phone number, highly inconvenient, and unreliable since it will often reject or silently fail to work with VoIP numbers.
SMS MFA is indeed bad, but it's also not what GitHub uses, at least not by default (you can either use Github's own mobile app or a dedicated MFA app like Google Authenticator). So it's incredibly unlikely that this is why people are whining about Github choosing to mandate MFA. I'm not particularly sold on the idea that "looking at another screen" is enough of an inconvenience to overcome the degree of benefit to security MFA provides.
Reading and typing in a 6 digit number is fine. What's not fine is how damn often you're forced to do it on some systems. Once a month I can tolerate but some systems require every week or every...
Reading and typing in a 6 digit number is fine. What's not fine is how damn often you're forced to do it on some systems. Once a month I can tolerate but some systems require every week or every day. It's way too aggressive for services that are regularly accessed from the same device.
The best option I know (and use) is a password manager that can function as an OTP generator. I use Bitwarden. I press Ctrl+L to fill in my credentials on the login form, but it also copies the...
Right now the best option for most is time-based one time password systems a la google authenticator.
The best option I know (and use) is a password manager that can function as an OTP generator.
I use Bitwarden. I press Ctrl+L to fill in my credentials on the login form, but it also copies the OTP to my clipboard. Then, as the next page comes and I have to fill that in, I can do so conveniently by pressing Ctrl+V.
To login to Bitwarden I use a hardware token as second factor, so the whole chain is still MFA.
convenience is the enemy of security. if you have Bitwarden store both your password and the TOTP secret in this way, it is more convenient, but you are degrading the security to basically the...
convenience is the enemy of security. if you have Bitwarden store both your password and the TOTP secret in this way, it is more convenient, but you are degrading the security to basically the same as if you didn't use TOTP at all for that site.
the original point of MFA is that if your password is compromised, having that 2nd factor on a separate device means that just knowing the password isn't enough.
yes, your Bitwarden account may be secured with MFA, but that doesn't protect against all classes of attack. an exploit against the browser extension, for example, might allow an attacker to access the entire contents of your decrypted vault.
if that happens, from the attacker's perspective there's no difference between sites where you logged in with only a password, and sites where you logged in with a password plus a TOTP token generated from a key stored in the vault. the contents of your vault act as a single factor that allows them to authenticate, even to sites supposedly protected by 2FA.
certainly, if you're willing to make this tradeoff based on your own personal threat model then have at it, but I would be cautious about recommending it to other people without a clear explanation of the tradeoffs.
Well, that is not completely true. This still protects me from attackers that somehow have guessed/stolen/brute forced my password and have thus gotten only access to one factor of the...
f you have Bitwarden store both your password and the TOTP secret in this way, it is more convenient, but you are degrading the security to basically the same as if you didn't use TOTP at all for that site.
Well, that is not completely true. This still protects me from attackers that somehow have guessed/stolen/brute forced my password and have thus gotten only access to one factor of the authentication. There are still two factors necessary to get in and the password is only one of them.
You are right that if the Bitwarden extension is compromised, the attacker gets hold of both factors. However, I'd say that once we get to the point of compromised browsers and extensions, you've already lost, because then the attacker can steal anything you have access to and show you anything they want. This includes stealing the OTP you generated on your separate device.
this is a huge leap. having a disclosure of your decrypted vault is not the same thing as having an omnipotent attacker who can access other arbitrary systems. Alice and Bob both have Bitwarden...
I'd say that once we get to the point of compromised browsers and extensions, you've already lost, because then the attacker can steal anything you have access to and show you anything they want. This includes stealing the OTP you generated on your separate device.
this is a huge leap. having a disclosure of your decrypted vault is not the same thing as having an omnipotent attacker who can access other arbitrary systems.
Alice and Bob both have Bitwarden accounts. Alice stores her TOTP keys in Bitwarden, like you're advocating. Bob does not.
Alice and Bob both have their unencrypted vaults disclosed to an attacker.
that attacker can now impersonate Alice on any website she had saved in her vault, without needing any additional information. everything they need is right there in the vault.
(This One Weird Trick Reduces Two-Factor Authentication Into A Single Factor)
meanwhile, the attacker can impersonate Bob, but only on websites in his vault that don't use 2FA. for websites that do use 2FA, they have an additional hurdle of trying to access the TOTP keys stored on Bob's phone. that's not at all guaranteed. if the original exploit was some zero-day in Chrome or whatever that allows bypassing the extension sandboxing mechanisms, that doesn't help them at all in hacking Google Authenticator or Authy or Aegis on Bob's phone.
(or, they can try to phish Bob and convince him to enter his 2FA code, but that requires active participation from Bob, whereas it didn't with Alice. and if they can successfully phish Bob, they could just steal his password and 2FA code that way and don't need to hack his Bitwarden vault in the first place)
this sort of disclosure of your entire unencrypted vault is basically the worst case scenario for anyone who uses a password manager. the one saving grace if it happens is that you can have high-value accounts such as your email and banking that aren't compromised because they use MFA. if you store the MFA keys alongside the passwords, you throw away that vital last line of defense.
Ok, I'll take your point. Thanks for explaining. Personally I am not too worried about this because my real important accounts fall in either of two categories: accounts where I can set up MFA...
Ok, I'll take your point. Thanks for explaining.
Personally I am not too worried about this because my real important accounts fall in either of two categories: accounts where I can set up MFA with a hardware token, my Yubikey, and accounts where the service insists that the only possible MFA is with SMS or their shitty app. Unfortunately the latter type is by far in the majority, but both fall outside the scenario discussed here.
But you are right, this is a personal evaluation that might be different for others. Let this exchange serve them as a guidance. Thanks again for pointing it out.
(answer only if you want to, of course) But I wanted to ask whether you have more than one yubikey, and also where you keep it, e.g. if with your regular keychain that could potentially fall...
my Yubikey
(answer only if you want to, of course)
But I wanted to ask whether you have more than one yubikey, and also where you keep it, e.g. if with your regular keychain that could potentially fall victim to theft, or somewhere else that's probably safer but less convenient…
No problem. I have two keys, because losing one would really suck if I didn't have a spare. One is on my desk, so always within reach when working, and the other is on my keychain, so I always...
No problem. I have two keys, because losing one would really suck if I didn't have a spare. One is on my desk, so always within reach when working, and the other is on my keychain, so I always have it with me if I am outside my house.
I am not too worried about someone else stealing it and getting access. It is two-factor, they don't have the passwords (or the usernames) and they don't know what services I use. But more important, most likely a thief is just interested in selling my devices and would ignore the key. I don't think I am interesting enough for a targeted physical attack. (As opposed to a targeted phishing attack, for instance.)
For years I have been rather paranoid about privacy and security, to the point that started to become a problem to function in the 'normal' world. Nowadays I try to follow the advice that you don't need an unbreakable lock (that doesn't exist), you just need to have a better lock than your neighbours.
From the perspective of each website, storing the TOTP within one’s password manager is still two factor. The password (something known) and the TOTP generated by a possessed device (something...
From the perspective of each website, storing the TOTP within one’s password manager is still two factor. The password (something known) and the TOTP generated by a possessed device (something possessed). Just so happens the password is remembered by the same possessed device. If the website has a breach, or your password is otherwise leaked/intercepted/guessed, an attacker is still missing the TOTP generating device(s).
What it does open up is if your master password and vault are obtained and decrypted, the keys to the kingdom are had in one go. I’m not familiar with the measures password managers such as 1Password take to prevent malicious browser extensions from accessing the raw vault data (including the TOTP seed key), but I imagine there are some in place.
Just to make sure, because what you're describing does sound like a nice solution to an issue/process I haven't properly (read: convincingly) set up for myself yet: Multiple installations of...
Just to make sure, because what you're describing does sound like a nice solution to an issue/process I haven't properly (read: convincingly) set up for myself yet:
Multiple installations of Bitwarden can function as the OTP generator active at the same time, right? So that you're not absolutely screwed if something happens to the "main" device.
If by "multiple installations of Bitwarden" you mean multiple Bitwarden clients (app, plugins, online vault) that use the same Bitwarden server (official cloud service, or selfhosted) to...
If by "multiple installations of Bitwarden" you mean multiple Bitwarden clients (app, plugins, online vault) that use the same Bitwarden server (official cloud service, or selfhosted) to synchronize, then yes.
The easiest way to look at it is this: that QR code that you scan when you set up a OTP for some random web service contains a code that lets authenticators generate the OTP. This code, also called "authenticator key", is simply a long string of letters and numbers that look like this: QAAJNZMP7NGQGRM7XJK2S2AQ3BAQF....
This authenticator key is stored in Bitwarden alongside you username and password and other details of your account for that web service. It is also synchronized to all your apps together with your username and password. So even if you have never accessed the web service before with your phone, only with your laptop, the Bitwarden app on your phone got this key together with your username and password from the central server and is able to generate a valid OTP from that.
I agree, MFA really should be the bare minimum and there's a certain responsibility that github could own by mandating MFA. When Discord mandated MFA for admins of discords of certain varieties I...
I agree, MFA really should be the bare minimum and there's a certain responsibility that github could own by mandating MFA.
When Discord mandated MFA for admins of discords of certain varieties I thought that if there's enough buy-in on this, then we've really turned a corner, and an important one, in terms of understanding our individual roles in information security (in the most casual of ways). I think most people just enabled it because they had to, otherwise they might lose control over the place they meme in real time or whatever, but at least there is an element of normalizing the use of MFA.
(Edit: I've been corrected below.) The caveat to all of this is that MFA means there are fewer degrees of separation between github and an individual's identity. And maybe more hurdles to retain anonymity. I think that'll be the primary point of concern people raise: there are many privacy-minded individuals who want to submit, contribute, audit, and interact on github. Obvious anonymizing methods aside, MFA means that github will know more about the majority of individuals, because they won't bother to retain their anonymity, than they did before this was mandated.
Absolutely untrue. Both TOTP and most ways of using U2F are privacy preserving. TOTP in particular is super simple and understandable and when understood obviously can't deanonomise anyone
The caveat to all of this is that MFA means there are fewer degrees of separation between github and an individual's identity.
Absolutely untrue. Both TOTP and most ways of using U2F are privacy preserving.
TOTP in particular is super simple and understandable and when understood obviously can't deanonomise anyone
I'm probably mistaken then, but I thought that the Time-based, One-Time Password, commonly used in conjuction with a smartphone app, would require a user to utilize an app on an internet-connected...
I'm probably mistaken then, but I thought that the Time-based, One-Time Password, commonly used in conjuction with a smartphone app, would require a user to utilize an app on an internet-connected device, whether it has a MAC or an IMEI or other unique identifier that may be linked to them, so that they can use the TOTP. The whole thing requires using a third-party service like Google's or Authy's, right?
Anyhow, I'm in favor of github's move to MFA. I'm not aware of any good arguments against using MFA more often than we typically we do.
No, that's not how TOTP works. The closest thing to a "network connection" you need on the device which generates the codes is an accurate clock. The OTP is essentially a hash of a shared secret...
No, that's not how TOTP works. The closest thing to a "network connection" you need on the device which generates the codes is an accurate clock. The OTP is essentially a hash of a shared secret and the current time; no additional state is required. The algorithms for computing them are standardized, which is why you can use any of dozens of "authenticator" apps, including free software and desktop ones, to generate them.
It's horrifyingly inelegant and not particularly user-friendly, but from a freedom/privacy philosophical perspective, TOTP is perfectly acceptable.
There are proprietary OTP implementations out there (banks in particular seem ironically fond of rolling their own security measures), but "TOTP" is not one of them.
I don’t think this is correct. The text string used in the initial QR code is all you need in order to generate correct tokens at the right time. This can happen from any offline device. As an...
I don’t think this is correct. The text string used in the initial QR code is all you need in order to generate correct tokens at the right time. This can happen from any offline device.
As an example, I use 1Password for all my 2fa tokens. It syncs these to all of my devices and even supports auto fill.
It does take the second “device” out of 2fa, but the second factor is definitely still there. Without unlocking my vault, I can’t access my 2fa codes, and I do this each time with a biometric scan.
For my purposes I find it a really nice balance between extra security and convenience.
Yeah but... how does that reduce the distance between Github and someone's identity? Nevermind of course that smartphones are far from the only way to generate OTPs, it just happens that we...
Yeah but... how does that reduce the distance between Github and someone's identity?
Nevermind of course that smartphones are far from the only way to generate OTPs, it just happens that we virtually all have one already.
It depends what you're worried about. If you're worried about the website, the browser acts as the intermediary and there's no additional IP address shared with the website. Whenever you log in to...
It depends what you're worried about. If you're worried about the website, the browser acts as the intermediary and there's no additional IP address shared with the website.
Whenever you log in to a website, it's easier for the website to keep a profile of what you did while logged in, and if you're not careful about anonymity then it could get connected to something else you did. Better login security doesn't really change this. It does make it harder to share your account or credibly argue that someone stole your password.
On the other hand, if you don't trust your browser? Well, you've got bigger problems, but yes, it would give the browser more info about who you are.
A third-party service isn't required (there is none for a Yubikey), but many auth apps have a way to sync your private information between different devices, and that's a potential vulnerability.
The issues are pretty similar when using a password manager; it's hard to make syncing sensitive data like that easy without making it less secure.
Github announced this in May of last year that forum post mentions not wanting to download a 2FA smartphone app, but there are other options, such as FIDO2/WebAuthn keys, which run as cheap as...
that forum post mentions not wanting to download a 2FA smartphone app, but there are other options, such as FIDO2/WebAuthn keys, which run as cheap as $15.
given the rise of supply-chain attacks, this is the right move for GitHub to make, even if it inconveniences a few users.
I try to avoid 2FA because I am under the impression that if I drop my phone in the lake, that's it. I can't regain access to my accounts. Is this an incorrect assumption?
I try to avoid 2FA because I am under the impression that if I drop my phone in the lake, that's it. I can't regain access to my accounts. Is this an incorrect assumption?
If your 2FA app has recovery or backup options, then this is not the case. Authy, for example, can recover from phone destruction to various degrees of severity.
If your 2FA app has recovery or backup options, then this is not the case. Authy, for example, can recover from phone destruction to various degrees of severity.
Follow-up question: what good open-source authenticator apps exist for Android and Linux (and iOS)? I have been using Google Authenticator but it does not appear to have backup options other than...
Follow-up question: what good open-source authenticator apps exist for Android and Linux (and iOS)? I have been using Google Authenticator but it does not appear to have backup options other than syncing with a Google account (??? which seems counterproductive), so I probably should switch.
You could use bitwarden, but TOTP functionality is paid and you shouldn’t store passwords and TOTP together anyways since that’s a single point of failure.
You could use bitwarden, but TOTP functionality is paid and you shouldn’t store passwords and TOTP together anyways since that’s a single point of failure.
Keepass has Totp plug-in and keepassxc support totp natively. Both are open source. Again, it is not recommended to store both your password and totp to the same database like u/Aldehyde mentioned.
Keepass has Totp plug-in and keepassxc support totp natively. Both are open source.
Again, it is not recommended to store both your password and totp to the same database like u/Aldehyde mentioned.
With Google Authenticator you can use "transfer accounts" to generate a backup QR code, take a picture of it, then store it somewhere safe (like printing it out and putting it in your sock...
With Google Authenticator you can use "transfer accounts" to generate a backup QR code, take a picture of it, then store it somewhere safe (like printing it out and putting it in your sock drawer).
Earlier this year I dropped my phone and it wouldn't power on. I was able to use my backup QR code to restore everything in Google Authenticator.
Getting locked out is an important risk to be wary of and that's why you should have multiple ways to get in. GitHub has good support for this. For many people, printing out backup codes and...
Getting locked out is an important risk to be wary of and that's why you should have multiple ways to get in. GitHub has good support for this.
For many people, printing out backup codes and storing them with your important papers is a good fallback plan, though you might be locked out for a while if you're away from home, so it's more of a last-resort thing. If you have two or more devices, you could register all of them so you're okay if you lose one.
GitHub supports passkeys. It's a nice way to log in on a phone or tablet, and you can also use it cross-device with a QR code. I also have a Yubikey on my keychain but since it's USB2, it doesn't work for everything.
One thing that's nice about it is that once you have this all set up, there are lots of other websites you can log into from GitHub. (Mostly developer-related.) I like having a sign-on system that's independent of Google to reduce my reliance on them a bit.
In addition to whatever backup options are available in your 2FA app of choice, generally when you sign up for 2FA you're given a set of backup codes to save in a safe place for if you can't...
In addition to whatever backup options are available in your 2FA app of choice, generally when you sign up for 2FA you're given a set of backup codes to save in a safe place for if you can't authenticate as usual. So if you drop your phone in a lake, you'd still be able to log in (and then switch your 2FA to your new phone) with those.
This is a good thing and I already have it enabled. I host my professional work on GitHub and it acts as my primary backup so extra protection is absolutely worth it.
This is a good thing and I already have it enabled. I host my professional work on GitHub and it acts as my primary backup so extra protection is absolutely worth it.
And as always, the average user will have no recourse when they lose their 2FA codes (due to a flood, for-instance), while maintainers of large repositories will have premium™ HN/Twitter (sorry,...
And as always, the average user will have no recourse when they lose their 2FA codes (due to a flood, for-instance), while maintainers of large repositories will have premium™ HN/Twitter (sorry, X) support. At least make it opt-out for those of us without blue checkmarks.
I don't think this is an issue, but so called "cold wallets" for this kind of thing as a last measure should be more popular. Especially with the popularity of 2FA. Having at least some sort of...
I don't think this is an issue, but so called "cold wallets" for this kind of thing as a last measure should be more popular. Especially with the popularity of 2FA. Having at least some sort of robust backup at home seems like a must.
Maybe if you had to tap your security key to your phone every once in a while.
I have a really hard time understanding their reticence to use a better security measure. To me, this is the equivalent of saying "I will absolutely not use a symbol in my password".
As for this part: "If I cannot opt out of 2FA, please point me to information on how to migrate my source code off of GitHub to another provider, such as GitLab, BitBucket, or similar." It is an empty threat. You could just google this, they just wanted to add that to make it sound like a threat.
I'm actually totally on board with not using software written by someone who is that adamant against an important and simple security measure.
I use ssh-keygen to generate public/private keys for authenticating against GitHub. I don't see any reason to give them my phone number or install yet another piece of software on my computer. Why isn't using ssh-keygen sufficient security?
Compromised how? Even if github leaks password hashes you'll be fine with your randomly generated 20 symbols long password from password manager of choice.
Of all the apps, a good TOTP app is one well worth having. You can also use Passkey functionality on your iOS/Android phone and skip the app altogether, though Firefox doesn’t currently support it.
Afaik a bunch of scientific institutions (including a data center on my university campus) were infiltrated (for data exfiltration and bitcoin mining in their high performance computation center) a year or two ago, because some guy with access to the data center didn't follow policy and thought leaving their ssh key lying around on their laptop unencrypted (aka without a passphrase) wasn't to bad.
You also have the option to use a hardware token such as a yubikey as a second factor. No phonenumber or app required.
According to this, git command line access over SSH isn't affected by MFA. It's just when you need to log into your account via the browser. So daily operations like git clone/push/pull won't require MFA if you configure your remote to use SSH. But if you wanted to modify your key / add a new key, you would need MFA to do so.
I think the extra security is well worth it. You don't even have to use their app: I use Eagis for example, which is FOSS.
https://getaegis.app/. There you go
Can you use ssh-keygen to log into GitHub's website?
Pretty sure you can't, and logging into the website using username and password is also how you add new ssh keys to the account.
Well put!
This is why developers that behave this way and don't care about security at all are not liked by the security and systems teams at companies... whether these are 'rockstar' or 'primmadonna' developers or not, this doesn't excuse that behaviour and childishness.
This seems overly performative to me. I don’t think GitHub wronged you and can’t understand the intense reaction. I don’t mind someone moving their code to a different host. Please host where you most enjoy the experience. But why involve this website in the process? You’re not here for our input.
I dont think this is totally fair. If you agree, it's fine to comment that you agree, but if you disagree and post about it it's performative?
Or alternately, if you say you are going to do something it's a bluff, but if you actually did it it's performative?
What's the valid way to express an opinion that isnt performative? I agree everyone who is upset could just silently leave github and not talk about it, but its a forum, you're supposed to talk about stuff.
By saying "empty threat" I did not mean "they won't do it". What I meant was "they are saying it to get attention". If it was simply "if you do this, I will leave" then that's fine and people generally don't care if a small subset of users leave (I bet it's expected and worthwhile to improve the security), but I instead it was "do this or show me how to get off the platform". That is one of the easiest thing to google and I don't believe for a second that these people can't figure out how to google exactly that.
It was all performative to get attention, probably due to frustration on the user's part. I am not saying it was malicious, but it was definitely attention seeking behavior, maybe to attempt to get this reversed.
Edit: I just realized you are the same person as the linked post. This makes it a lot more personal than talking in the abstract about the post of a random person. I will leave this up because I stand behind it, but I don't mean to attack you directly.
I don't know about highly technical users, but 2FA for me is like saying "You will eventually lose access to your account and there's nothing you can do about it". I've seen it happen multiple times. You know what have I never seen in real life? A third party stealing someone's account. From my layman's perspective, 2FA is a greater risk than hackers.
Wait, really? You've actually never heard of someone obtaining someone else's credentials and using them to take over their account? Or am I not understanding something?
I've literally never seen it happen with anyone in real life. But I've seen multiple accounts lost to 2FA and other "ultra-secure" mechanisms.
2FA scares me to death.
I don't know anyone who has lost a 2FA if you want counter-anecdotal experience. There are tools like Authy that can backup your 2FA across multiple devices.
And how do you backup Authy?
Through Authy itself: How Authy 2FA Backups Work
It's multi factor security, not iron proof security. If someone breaks into your authy, they still need to break your password. If someone breaks your password, yet still need your authy. It greatly reduces the chance that a single provider getting hacked will lead to account hijacking.
You need to be thinking more broadly, not just of a targeted attack on your machine. That's typically the least likely attack to experience for the average person.
The advantage of MFA with rotating codes vs. SSH keys is that most websites don't let you paste or feed in an SSH key. It's an ease of use and accessibility issue. I don't think our current iteration of MFA is the final state of what it should be, though.
Have you tried to onboard brand new software engineers recently? It is significantly easier to get them to use and understand Authy or Google Authenticator compared to SSH keys. Additionally they probably already need these applications for other company resources / SSO.
A big part of that issue is the general lack of assistance with ssh keys. Documentation and instruction are either whitepaper level or "just do it lol". Services almost never specify what parameters they require for ssh keys, but they definitely do have requirements that you need to nail or you get a basic "something's wrong" error. And Windows likes to pretend ssh doesn't even exist, except when it does and you better do it exactly as Microsoft wants but doesn't explain or you'll be fighting gremlins constantly.
Essentially, everyone does a shit job of handling ssh keys, so no wonder people struggle to learn/use them. I agree they are great but the tooling and UX could be so so so greatly improved.
Additionally you can export the QR codes with an older version of authy. Instructions
It's pretty recoverable through some identity verification checks, and most services provide recovery codes that can be safely stored in case one loses access to their 2FA device. It's been a failsafe for nearly as long as 2FA has been around. I've lost entire 2FA devices that rendered me unable to access many of my accounts, and I got access back within an hour or two.
I have to imagine that most cases of people losing access to an account for any lengthy period of time due to 2FA have some degree of negligence involved or something went very wrong in the process at some point.
It is unfortunate that real people don't really know or care about theory.
Keys and locks are simple and intuitive metaphor. My father, mother, and grandparents all understand it, no education required.
A lot of the times, 2FA is only really perceived as something more than a nuisance when you lose your smartphone, only to realize that your password is now completely useless.
With all due respect, but it's incredibly out of touch to think grandma will keep a dozen recovery codes in her purse. Or even know what recovery codes are.
Programmers are highly capable at programming, but are seemingly not as capable of anticipating the needs of less technical users.
Grandma isn't going to use GitHub, though. I think if someone can wrap their head around git they can use recovery codes.
Sure. 2FA, or even something more complicated, absolutely makes sense for GitHub specifically.
I just get ranty about 2FA. You can mark all of that as off topic.
Oh no worries. I think it's on topic enough.
I used to hate 2FA too, and I lost all my authenticators once when my phone broke. After that I invested some time in figuring out how to have them backed up (I used the paid version of Authenticator Plus but Authy provides the same functionality for free), then later moved them all to my 1Password vault which I can access on all my devices (protected by a secret key and master password, which I have printed and locked away). 1P on my laptop locks itself after 1 minute of inactivity, and once it is unlocked it can just fill in 2FA codes for me quickly. It has made 2FA painless for me and I would recommend it.
However, yeah, Grandma isn't gonna do any of that. But if she really needed 2FA she could probably handle getting codes via SMS or email if someone explained it to her. I definitely support it being optional for most apps/sites.
Grandma lost her prepaid phone. Grandma does not own a computer. Grandma's email itself requires 2FA. Grandma is in a loop. Now grandma lost her accounts. Grandma can't message her doctor. Grandma is now dead.Mostly true story.
That's why I keep a recovery code in a couple articles of clothing. Got some washer proof custom stickers made with a simple cipher to make it less obvious what it is.
I'm speaking about people that are capable and have put in the work to understand 2FA enough to actually use and apply it. I find it hard to believe it would lead to someone inevitably losing their account when there's so many ways to recover an account should the 2FA device go missing. The recovery codes are just one method, most services seem to use email or phone verification instead as a backup which is a friendlier approach to many who aren't up to speed with tech.
And since this is GitHub, the assumption of technical competence among the userbase is reasonably a lot higher than most other services or tools. I'd hope that if grandma is slinging code to FOSS tools, she'd be capable of figuring out 2FA recovery codes.
Of course there will be people who simply can't grasp it and will have trouble but solving for them is another issue that has plagued technology as a concept forever, especially when it comes to security (where the inherent inconvenience means it meets more resistance than most other tech). At some point, it's about what's necessary to have a minimum level of security and everyone having to adapt to preserve overall integrity. It used to be that one alphabet-only password of 8 characters was enough, but that hasn't been the case in a long time.
Solving for the technologically illiterate is another issue entirely. In a casual way, there's always been the concept of helping family members and the like to protect their interests. Before computers, children helped parents modernize their banking and insurance setups, get their government paperwork in place, set up monthly payments for new bills and utilities, etc. Managing digital accounts isn't a step away from this. I'd hope that if someone is helping their parents or grandparents make necessary accounts with necessary security, they're also doing things like making their own backups of those recovery codes or account information when necessary.
There are always recovery codes
I'm absolutely fine with mandating extra security (as if MFA isn't bare minimum) on a place that frequently hosts repositories referenced deep inside other programs that never get another thought and that is linked to as a generally safe downloading place for software. Protecting every link in that software distribution chain is important.
As a a slightly exasperated IT professional I also can't grasp any objection to MFA. Yes it's slightly inconvenient, but it is literally a bare minimum requirement to make sure your users are protected in a world of weak, reused passwords and incredibly skilled phishing attempts.
If you truly can't stand involving a physical phone in the process, there are open source MFA key programs you can install on whatever computer you're currently working on instead of a phone. If the goal is to be able to access the site from anywhere on public computers, get a portable token generator no bigger than a flash drive and throw it on your keychain.
The security world is moving to abandon passwords completely wherever possible for good reason, as bad actors continue to improve their methods you need another layer of protection on your accounts.
It's really more about people irritated about inconvenient or badly implemented security measures.
One of the websites I go to cannot seem to figure out cookies and so I'm constantly needing to log in, and their login form is so messed up that my password manager doesn't seem to want to work with it.
A lot of businesses implement MFA in the form of tokens sent via SMS. That's both invasive, since it requires your phone number, highly inconvenient, and unreliable since it will often reject or silently fail to work with VoIP numbers. Sometimes they send tokens to your email which is especially irritating since email is an inherantly unreliable service. I've had plenty of times where it took so long to get a token email that the token was already expired by the time it got to me. I've had even more times when I grew impatient waiting for one to get sent that I think it just isn't coming so I send out another request, and when I finally get the first token it doesn't work and attempting to use it has invalidated the second token as well.
Hardware based tokens are nice, but nobody owns them, and they have their own downfalls as well. Right now the best option for most is time-based one time password systems a la google authenticator. But even then it's not really convenient unless you're using a synced password manager so you're not glancing across screens and carefully trying to enter the token and submit it before the time limit.
SMS MFA is indeed bad, but it's also not what GitHub uses, at least not by default (you can either use Github's own mobile app or a dedicated MFA app like Google Authenticator). So it's incredibly unlikely that this is why people are whining about Github choosing to mandate MFA. I'm not particularly sold on the idea that "looking at another screen" is enough of an inconvenience to overcome the degree of benefit to security MFA provides.
Of course. I am addressing why people resist MFA generally.
By all means MFA should be mandatory.
Reading and typing in a 6 digit number is fine. What's not fine is how damn often you're forced to do it on some systems. Once a month I can tolerate but some systems require every week or every day. It's way too aggressive for services that are regularly accessed from the same device.
SMS as a form of MFA can also be less secure than a good password: SIM swapping attacks are pretty common nowadays.
That SMS/Text message is less secure than an authenticator is correct, but it is still more secure than not having MFA at all.
If SMS can be used for a password reset, then it's a gaping security hole.
The best option I know (and use) is a password manager that can function as an OTP generator.
I use Bitwarden. I press Ctrl+L to fill in my credentials on the login form, but it also copies the OTP to my clipboard. Then, as the next page comes and I have to fill that in, I can do so conveniently by pressing Ctrl+V.
To login to Bitwarden I use a hardware token as second factor, so the whole chain is still MFA.
convenience is the enemy of security. if you have Bitwarden store both your password and the TOTP secret in this way, it is more convenient, but you are degrading the security to basically the same as if you didn't use TOTP at all for that site.
the original point of MFA is that if your password is compromised, having that 2nd factor on a separate device means that just knowing the password isn't enough.
yes, your Bitwarden account may be secured with MFA, but that doesn't protect against all classes of attack. an exploit against the browser extension, for example, might allow an attacker to access the entire contents of your decrypted vault.
if that happens, from the attacker's perspective there's no difference between sites where you logged in with only a password, and sites where you logged in with a password plus a TOTP token generated from a key stored in the vault. the contents of your vault act as a single factor that allows them to authenticate, even to sites supposedly protected by 2FA.
certainly, if you're willing to make this tradeoff based on your own personal threat model then have at it, but I would be cautious about recommending it to other people without a clear explanation of the tradeoffs.
Well, that is not completely true. This still protects me from attackers that somehow have guessed/stolen/brute forced my password and have thus gotten only access to one factor of the authentication. There are still two factors necessary to get in and the password is only one of them.
You are right that if the Bitwarden extension is compromised, the attacker gets hold of both factors. However, I'd say that once we get to the point of compromised browsers and extensions, you've already lost, because then the attacker can steal anything you have access to and show you anything they want. This includes stealing the OTP you generated on your separate device.
this is a huge leap. having a disclosure of your decrypted vault is not the same thing as having an omnipotent attacker who can access other arbitrary systems.
Alice and Bob both have Bitwarden accounts. Alice stores her TOTP keys in Bitwarden, like you're advocating. Bob does not.
Alice and Bob both have their unencrypted vaults disclosed to an attacker.
that attacker can now impersonate Alice on any website she had saved in her vault, without needing any additional information. everything they need is right there in the vault.
(This One Weird Trick Reduces Two-Factor Authentication Into A Single Factor)
meanwhile, the attacker can impersonate Bob, but only on websites in his vault that don't use 2FA. for websites that do use 2FA, they have an additional hurdle of trying to access the TOTP keys stored on Bob's phone. that's not at all guaranteed. if the original exploit was some zero-day in Chrome or whatever that allows bypassing the extension sandboxing mechanisms, that doesn't help them at all in hacking Google Authenticator or Authy or Aegis on Bob's phone.
(or, they can try to phish Bob and convince him to enter his 2FA code, but that requires active participation from Bob, whereas it didn't with Alice. and if they can successfully phish Bob, they could just steal his password and 2FA code that way and don't need to hack his Bitwarden vault in the first place)
this sort of disclosure of your entire unencrypted vault is basically the worst case scenario for anyone who uses a password manager. the one saving grace if it happens is that you can have high-value accounts such as your email and banking that aren't compromised because they use MFA. if you store the MFA keys alongside the passwords, you throw away that vital last line of defense.
Ok, I'll take your point. Thanks for explaining.
Personally I am not too worried about this because my real important accounts fall in either of two categories: accounts where I can set up MFA with a hardware token, my Yubikey, and accounts where the service insists that the only possible MFA is with SMS or their shitty app. Unfortunately the latter type is by far in the majority, but both fall outside the scenario discussed here.
But you are right, this is a personal evaluation that might be different for others. Let this exchange serve them as a guidance. Thanks again for pointing it out.
(answer only if you want to, of course)
But I wanted to ask whether you have more than one yubikey, and also where you keep it, e.g. if with your regular keychain that could potentially fall victim to theft, or somewhere else that's probably safer but less convenient…
No problem. I have two keys, because losing one would really suck if I didn't have a spare. One is on my desk, so always within reach when working, and the other is on my keychain, so I always have it with me if I am outside my house.
I am not too worried about someone else stealing it and getting access. It is two-factor, they don't have the passwords (or the usernames) and they don't know what services I use. But more important, most likely a thief is just interested in selling my devices and would ignore the key. I don't think I am interesting enough for a targeted physical attack. (As opposed to a targeted phishing attack, for instance.)
For years I have been rather paranoid about privacy and security, to the point that started to become a problem to function in the 'normal' world. Nowadays I try to follow the advice that you don't need an unbreakable lock (that doesn't exist), you just need to have a better lock than your neighbours.
From the perspective of each website, storing the TOTP within one’s password manager is still two factor. The password (something known) and the TOTP generated by a possessed device (something possessed). Just so happens the password is remembered by the same possessed device. If the website has a breach, or your password is otherwise leaked/intercepted/guessed, an attacker is still missing the TOTP generating device(s).
What it does open up is if your master password and vault are obtained and decrypted, the keys to the kingdom are had in one go. I’m not familiar with the measures password managers such as 1Password take to prevent malicious browser extensions from accessing the raw vault data (including the TOTP seed key), but I imagine there are some in place.
Just to make sure, because what you're describing does sound like a nice solution to an issue/process I haven't properly (read: convincingly) set up for myself yet:
Multiple installations of Bitwarden can function as the OTP generator active at the same time, right? So that you're not absolutely screwed if something happens to the "main" device.
If by "multiple installations of Bitwarden" you mean multiple Bitwarden clients (app, plugins, online vault) that use the same Bitwarden server (official cloud service, or selfhosted) to synchronize, then yes.
The easiest way to look at it is this: that QR code that you scan when you set up a OTP for some random web service contains a code that lets authenticators generate the OTP. This code, also called "authenticator key", is simply a long string of letters and numbers that look like this: QAAJNZMP7NGQGRM7XJK2S2AQ3BAQF....
This authenticator key is stored in Bitwarden alongside you username and password and other details of your account for that web service. It is also synchronized to all your apps together with your username and password. So even if you have never accessed the web service before with your phone, only with your laptop, the Bitwarden app on your phone got this key together with your username and password from the central server and is able to generate a valid OTP from that.
I agree, MFA really should be the bare minimum and there's a certain responsibility that github could own by mandating MFA.
When Discord mandated MFA for admins of discords of certain varieties I thought that if there's enough buy-in on this, then we've really turned a corner, and an important one, in terms of understanding our individual roles in information security (in the most casual of ways). I think most people just enabled it because they had to, otherwise they might lose control over the place they meme in real time or whatever, but at least there is an element of normalizing the use of MFA.
(Edit: I've been corrected below.)
The caveat to all of this is that MFA means there are fewer degrees of separation between github and an individual's identity. And maybe more hurdles to retain anonymity. I think that'll be the primary point of concern people raise: there are many privacy-minded individuals who want to submit, contribute, audit, and interact on github. Obvious anonymizing methods aside, MFA means that github will know more about the majority of individuals, because they won't bother to retain their anonymity, than they did before this was mandated.Absolutely untrue. Both TOTP and most ways of using U2F are privacy preserving.
TOTP in particular is super simple and understandable and when understood obviously can't deanonomise anyone
I'm probably mistaken then, but I thought that the Time-based, One-Time Password, commonly used in conjuction with a smartphone app, would require a user to utilize an app on an internet-connected device, whether it has a MAC or an IMEI or other unique identifier that may be linked to them, so that they can use the TOTP. The whole thing requires using a third-party service like Google's or Authy's, right?
Anyhow, I'm in favor of github's move to MFA. I'm not aware of any good arguments against using MFA more often than we typically we do.
No, that's not how TOTP works. The closest thing to a "network connection" you need on the device which generates the codes is an accurate clock. The OTP is essentially a hash of a shared secret and the current time; no additional state is required. The algorithms for computing them are standardized, which is why you can use any of dozens of "authenticator" apps, including free software and desktop ones, to generate them.
(Wikipedia, for reference.)
It's horrifyingly inelegant and not particularly user-friendly, but from a freedom/privacy philosophical perspective, TOTP is perfectly acceptable.
There are proprietary OTP implementations out there (banks in particular seem ironically fond of rolling their own security measures), but "TOTP" is not one of them.
I don’t think this is correct. The text string used in the initial QR code is all you need in order to generate correct tokens at the right time. This can happen from any offline device.
As an example, I use 1Password for all my 2fa tokens. It syncs these to all of my devices and even supports auto fill.
It does take the second “device” out of 2fa, but the second factor is definitely still there. Without unlocking my vault, I can’t access my 2fa codes, and I do this each time with a biometric scan.
For my purposes I find it a really nice balance between extra security and convenience.
Yeah but... how does that reduce the distance between Github and someone's identity?
Nevermind of course that smartphones are far from the only way to generate OTPs, it just happens that we virtually all have one already.
It depends what you're worried about. If you're worried about the website, the browser acts as the intermediary and there's no additional IP address shared with the website.
Whenever you log in to a website, it's easier for the website to keep a profile of what you did while logged in, and if you're not careful about anonymity then it could get connected to something else you did. Better login security doesn't really change this. It does make it harder to share your account or credibly argue that someone stole your password.
On the other hand, if you don't trust your browser? Well, you've got bigger problems, but yes, it would give the browser more info about who you are.
A third-party service isn't required (there is none for a Yubikey), but many auth apps have a way to sync your private information between different devices, and that's a potential vulnerability.
The issues are pretty similar when using a password manager; it's hard to make syncing sensitive data like that easy without making it less secure.
Github announced this in May of last year
that forum post mentions not wanting to download a 2FA smartphone app, but there are other options, such as FIDO2/WebAuthn keys, which run as cheap as $15.
given the rise of supply-chain attacks, this is the right move for GitHub to make, even if it inconveniences a few users.
I try to avoid 2FA because I am under the impression that if I drop my phone in the lake, that's it. I can't regain access to my accounts. Is this an incorrect assumption?
If your 2FA app has recovery or backup options, then this is not the case. Authy, for example, can recover from phone destruction to various degrees of severity.
Follow-up question: what good open-source authenticator apps exist for Android and Linux (and iOS)? I have been using Google Authenticator but it does not appear to have backup options other than syncing with a Google account (??? which seems counterproductive), so I probably should switch.
Android: Aegis
Linux: I just use the features in Bitwarden
You could use bitwarden, but TOTP functionality is paid and you shouldn’t store passwords and TOTP together anyways since that’s a single point of failure.
Keepass has Totp plug-in and keepassxc support totp natively. Both are open source.
Again, it is not recommended to store both your password and totp to the same database like u/Aldehyde mentioned.
With Google Authenticator you can use "transfer accounts" to generate a backup QR code, take a picture of it, then store it somewhere safe (like printing it out and putting it in your sock drawer).
Earlier this year I dropped my phone and it wouldn't power on. I was able to use my backup QR code to restore everything in Google Authenticator.
Issue with this method is that you have to create a new QR code every time you add a new login.
Getting locked out is an important risk to be wary of and that's why you should have multiple ways to get in. GitHub has good support for this.
For many people, printing out backup codes and storing them with your important papers is a good fallback plan, though you might be locked out for a while if you're away from home, so it's more of a last-resort thing. If you have two or more devices, you could register all of them so you're okay if you lose one.
GitHub supports passkeys. It's a nice way to log in on a phone or tablet, and you can also use it cross-device with a QR code. I also have a Yubikey on my keychain but since it's USB2, it doesn't work for everything.
One thing that's nice about it is that once you have this all set up, there are lots of other websites you can log into from GitHub. (Mostly developer-related.) I like having a sign-on system that's independent of Google to reduce my reliance on them a bit.
In addition to whatever backup options are available in your 2FA app of choice, generally when you sign up for 2FA you're given a set of backup codes to save in a safe place for if you can't authenticate as usual. So if you drop your phone in a lake, you'd still be able to log in (and then switch your 2FA to your new phone) with those.
This is a good thing and I already have it enabled. I host my professional work on GitHub and it acts as my primary backup so extra protection is absolutely worth it.
And as always, the average user will have no recourse when they lose their 2FA codes (due to a flood, for-instance), while maintainers of large repositories will have premium™ HN/Twitter (sorry, X) support. At least make it opt-out for those of us without blue checkmarks.
Use a passkey for authentication on GitHub! Then you don't have to worry about MFA at all, among other benefits.
I don't think this is an issue, but so called "cold wallets" for this kind of thing as a last measure should be more popular. Especially with the popularity of 2FA. Having at least some sort of robust backup at home seems like a must.
Maybe if you had to tap your security key to your phone every once in a while.
I enable 2FA but everyone flocking to github is a problem in the first place