Tell HN: GitHub locked me out for not using 2FA
69 comments
GitHub is slowly rolling out feature over moe than a year [1], which will have positive impact on overall IT security.
Spending 1 minute setting up 2FA is really not a big deal.
[1] https://github.blog/news-insights/product-news/raising-the-b...
Spending 1 minute setting up 2FA is really not a big deal.
[1] https://github.blog/news-insights/product-news/raising-the-b...
I wonder how much of the negative connotation in ~every GitHub thread comes from the MS buyout vs the actual topic under discussion. Do people really dislike 2FA on something as important as source hosting?
> something as important as source hosting?
But it's not important for a lot of people. Lots of people just create the occasional issue or some such. Almost no one is a maintainer of something important.
And overall it's just a hassle that adds zero security for me; I just have the tokens in the password manager next to the passwords (where else do I store it? I just have my laptop).
It's something that should be the user choice, based on how important the account is, personal factors, etc.
But it's not important for a lot of people. Lots of people just create the occasional issue or some such. Almost no one is a maintainer of something important.
And overall it's just a hassle that adds zero security for me; I just have the tokens in the password manager next to the passwords (where else do I store it? I just have my laptop).
It's something that should be the user choice, based on how important the account is, personal factors, etc.
I would actually be far more frustrated by mandatory 2FA at login than if my GitHub account were compromised. I use it to star projects, and because you can't code search without being logged in; it's a bottom-tier account for me and 2FA means I'll probably just not bother. Why can't they gate sensitive features behind 2FA?
As an aside, I'm surprised I've never seen an async authentication system whereby PW gets you in, 2FA code is sent, and you can continue accessing the system in a limited way until you submit your 2FA code, instead of sitting on some intermediary page waiting a few minutes for the code to arrive.
As an aside, I'm surprised I've never seen an async authentication system whereby PW gets you in, 2FA code is sent, and you can continue accessing the system in a limited way until you submit your 2FA code, instead of sitting on some intermediary page waiting a few minutes for the code to arrive.
2FA is a bigger problem to me than Microsoft. I'm not having electronics on me most of the time.
If i have to log in to Github from somewhere else, i call my landline and have SO read the 2FA code to me. But since this is cumbersome i try to get my stuff done without the Github login.
If i have to log in to Github from somewhere else, i call my landline and have SO read the 2FA code to me. But since this is cumbersome i try to get my stuff done without the Github login.
I do dislike it. I'd take back my only occasional contribution to a project not to be bothered by 2FA and I'm not submitting issues anymore to anything. Basically I'm using github in read only mode without logging in. When another customer of mine will use github I'll be back on it and I'll use 2FA, but at least they'll be paying me for the trouble. All my current customers are on bitbucket.
> Do people really dislike 2FA on something as important as source hosting?
"important" is a per-person individual decision.
A phrase that used to be very common is "mechanism, not policy".
The role of a vendor is supposed to be to enable mechanisms so that customers can implement whichever policy that best fits their needs.
The role of a customer is to choose and implement the policy that best works for them personally, using the mechanisms that the vendor provides.
It is fundamentally wrong for a vendor to impose policy, that's not their job. Nor do they have the information to correctly make that decision.
Some (few) people have important source code in their github account. I'd highly encourage those people to enable 2FA. Most people don't have anything important that anyone else uses, so adding the overhead of 2FA for them is beyond silly and purely obnoxious.
"important" is a per-person individual decision.
A phrase that used to be very common is "mechanism, not policy".
The role of a vendor is supposed to be to enable mechanisms so that customers can implement whichever policy that best fits their needs.
The role of a customer is to choose and implement the policy that best works for them personally, using the mechanisms that the vendor provides.
It is fundamentally wrong for a vendor to impose policy, that's not their job. Nor do they have the information to correctly make that decision.
Some (few) people have important source code in their github account. I'd highly encourage those people to enable 2FA. Most people don't have anything important that anyone else uses, so adding the overhead of 2FA for them is beyond silly and purely obnoxious.
> The role of a vendor is supposed to be to enable mechanisms so that customers can implement whichever policy that best fits their needs.
this is where GitHub isn't a vendor; it's almost a social network as one account getting compromised could potentially cascade through projects. If you want to manage the risk profile that best fits you; you'd localize on GitHub Enterprise or other selfhosting.
this is where GitHub isn't a vendor; it's almost a social network as one account getting compromised could potentially cascade through projects. If you want to manage the risk profile that best fits you; you'd localize on GitHub Enterprise or other selfhosting.
Very well put. I work in info sec and I find Githubs 2FA requirement completely obnoxious.
Because you can't use passwords anymore, you have to set up tokens, which are often stored in the clear. It's actually less secure for me than a reasonable password and a lot more hassle to maintain.
Should be a choice I make. I use GitHub a lot less now than I did before, it's a pain to use now. Maybe I'll move to something else that respects my choice and threat model.
Because you can't use passwords anymore, you have to set up tokens, which are often stored in the clear. It's actually less secure for me than a reasonable password and a lot more hassle to maintain.
Should be a choice I make. I use GitHub a lot less now than I did before, it's a pain to use now. Maybe I'll move to something else that respects my choice and threat model.
It somewhat breaks my workflow of downloading my (encrypted) password database from a private repo on GitHub when setting up a new computer. The keys used to generate TOTP codes are in the password database itself, so I can't use TOTP to log into GitHub.
So I have an email account without 2FA that receives the Github 2FA code.
So I have an email account without 2FA that receives the Github 2FA code.
Also if you really really hate two-factor authentication, e.g. due to psychological change resistance, there are multiple good alternatives like Bitbucket or Gitlab. Nobody is forcing you to use Github, and usually people do not even pay for it.
> Also if you really really hate two-factor authentication, e.g. due to psychological change resistance
Nearly all resistance to 2FA is because of fear of losing access to the 2FA device. I believe it's a well-earned resistance, because they've done a terrible job of explaining that there are alternatives in that case, such as special codes that you can write down and put in a safe.
Nearly all resistance to 2FA is because of fear of losing access to the 2FA device. I believe it's a well-earned resistance, because they've done a terrible job of explaining that there are alternatives in that case, such as special codes that you can write down and put in a safe.
GitHub prompts you to save backup codes when you set up 2FA, and every so often when you log in. I don't think that's a terrible job, it's pretty much the standard.
They also nudge you to set up multiple 2FA methods. I have the app, a passkey, etc.
They also nudge you to set up multiple 2FA methods. I have the app, a passkey, etc.
I don't bother much with the special back-up codes (although I do store them just in case). I just make sure I have the TOTP plaintext shared secrets stored on multiple devices.
One of the reasons I use Microsoft Authenticator instead of others is it allows me to back up the configuration to the Microsoft cloud. I've already followed the restore process several times over the course of replacing phones and it works well.
Authy backups work as well, have been using half a decade now.
Problem with Authy is you can't export your seeds externally, which sets you up for failure if Authy decides to turn into the next Raivo.
There is an unofficial method by using devtools on the desktop app, but it's been EOL for months and it may soon stop working completely.
There is an unofficial method by using devtools on the desktop app, but it's been EOL for months and it may soon stop working completely.
If you're interested in contributing to projects that are hosted on GitHub, but aren't in a position to be making decisions about whether to migrate them, then yeah, you're forced to use GitHub.
I've given up on using GitHub. Nothing else I use requires 2FA, I don't have a smart phone, and figuring out an alternative just to post bug reports is a waste of my time, so I've taken to emailing the developers instead.
The complete lack of consistency in MFA requirements just show no one knows what the fuck they're doing.
DoorDash: Every time I need to enter an SMS code.
UberEats: Same thing, SMS code every time.
Grubhub: No MFA ever. Wonderful.
Twitch: Every couple days I need to enter a code sent to my email (because I won't give them my phone number which they really really want me to give them).
Reddit: no MFA requirement...for now. Given how fucking garbage they've become I wouldn't be surprised if they start enforcing it soon.
Amazon: no MFA requirement despite sometimes asking.
GMail: no MFA requirement despite also asking.
DoorDash: Every time I need to enter an SMS code.
UberEats: Same thing, SMS code every time.
Grubhub: No MFA ever. Wonderful.
Twitch: Every couple days I need to enter a code sent to my email (because I won't give them my phone number which they really really want me to give them).
Reddit: no MFA requirement...for now. Given how fucking garbage they've become I wouldn't be surprised if they start enforcing it soon.
Amazon: no MFA requirement despite sometimes asking.
GMail: no MFA requirement despite also asking.
> I don't have a smart phone
GitHub’s 2FA gives you the option to use SMS. But even for the authenticator method you don’t need a phone, most decent password managers nowadays support saving (and auto-filling) 2FA tokens.
There’s also the option to print/write down the one-time codes. Though the latter would admittedly be a bother if you log out frequently.
Point being there’re many ways to go about it.
GitHub’s 2FA gives you the option to use SMS. But even for the authenticator method you don’t need a phone, most decent password managers nowadays support saving (and auto-filling) 2FA tokens.
There’s also the option to print/write down the one-time codes. Though the latter would admittedly be a bother if you log out frequently.
Point being there’re many ways to go about it.
Sure, but I don't like any of those options. I don't want Microsoft to have my phone number, I have like 15-20 logins, which is small enough to keep on paper [1], so I have no password manager, and I always logged out of GitHub since I generally log in to things via a private window.
I really, really don't like being tracked, "filed, stamped, indexed, briefed, debriefed, or numbered", so avoid accounts as much as possible, and all the more so from megacorporations.
[1] Correction: I originally said 10-15 but I remembered a few that are in the Firefox password manager, like archive.org.
I really, really don't like being tracked, "filed, stamped, indexed, briefed, debriefed, or numbered", so avoid accounts as much as possible, and all the more so from megacorporations.
[1] Correction: I originally said 10-15 but I remembered a few that are in the Firefox password manager, like archive.org.
I used to enjoy sharing some code for the benefit of the community, although less and less since SAS business models, and now AI training.
Mandatory 2fa feels like a step towards 'MS GitHub Certified Developer & Contributor' program. How else do you 'secure the supply chain' without having identified and accountable developers.
Mandatory 2fa feels like a step towards 'MS GitHub Certified Developer & Contributor' program. How else do you 'secure the supply chain' without having identified and accountable developers.
This feels like a slippery slope fallacy. I don’t trust Microsoft and don’t think they have user’s best interests at heart, but 2FA is generally accepted as a positive thing industry-wide. They’re far from the only ones to require it. See for example PyPI.
https://blog.pypi.org/posts/2024-01-01-2fa-enforced/
npm is another one, but because it’s owned by GitHub (and thus Microsoft) we can leave it out of the argument.
https://blog.pypi.org/posts/2024-01-01-2fa-enforced/
npm is another one, but because it’s owned by GitHub (and thus Microsoft) we can leave it out of the argument.
Why is it a fallacy? I stopped distributing on PyPI before the switch to 2FA because I could see it also going the "Certified Developer & Contributor" route, which is what often happens with centralized systems.
PyPI's later switch to 2FA confirmed my belief that they going further along that slope.
Centralized systems are hard to manage. We've seen how Anaconda and readthedocs have switched their business models to get more funding. PyPI uses a lot of bandwidth, and needs people to manage all of the attacks and abuse.
And you know who has money? Big businesses who want someone else to manage their supply chain. And you know who has the time to help manage these systems? People working for big businesses.
PyPI was able to require a change to 2FA in part because there aren't effective alternatives, nor the easy ability to migrate from one to another. Those who don't want to be part of the "industry" have a high switching cost.
Also, what does "industry-wide" mean? I distribute packages (source and binary wheels) on my own server. None of my commercial customers have ever even asked about 2FA. And if I am in the same industry, I can assure you I have never placed that requirement on my suppliers.
PyPI's later switch to 2FA confirmed my belief that they going further along that slope.
Centralized systems are hard to manage. We've seen how Anaconda and readthedocs have switched their business models to get more funding. PyPI uses a lot of bandwidth, and needs people to manage all of the attacks and abuse.
And you know who has money? Big businesses who want someone else to manage their supply chain. And you know who has the time to help manage these systems? People working for big businesses.
PyPI was able to require a change to 2FA in part because there aren't effective alternatives, nor the easy ability to migrate from one to another. Those who don't want to be part of the "industry" have a high switching cost.
Also, what does "industry-wide" mean? I distribute packages (source and binary wheels) on my own server. None of my commercial customers have ever even asked about 2FA. And if I am in the same industry, I can assure you I have never placed that requirement on my suppliers.
> I distribute packages (source and binary wheels) on my own server. None of my commercial customers have ever even asked about 2FA. And if I am in the same industry, I can assure you I have never placed that requirement on my suppliers.
a.k.a the "just trust me bro" approach.
Unfortunately the days where we can rely on trust alone are largely behind us.
Supply chain security is a real thing, even if "security vendors" over-hype it to sound like an impending doomsday.
If you work in an important industry, a leaked password should not result in a malicious package being pulled that takes out your <car/power plant/pacemaker/ insert important thing here>.
a.k.a the "just trust me bro" approach.
Unfortunately the days where we can rely on trust alone are largely behind us.
Supply chain security is a real thing, even if "security vendors" over-hype it to sound like an impending doomsday.
If you work in an important industry, a leaked password should not result in a malicious package being pulled that takes out your <car/power plant/pacemaker/ insert important thing here>.
> are largely behind us
So am I part of this industry or not? What even makes something an "important" industry vs. a non-important industry?
It seems odd how you point to "car/power plant/pacemaker" examples when few people with Microsoft GitHub accounts work in real-time systems, much less ones which risk human injury or death.
My business works with P.O.s, contracts, wire transfers, one-on-one interactions, customer knowledge of my 25 years of working in this field, and my ability to vet my customers.
That's where the "trust me" comes from, not bro-dom, not Microsoft with its long history of security failures.
So am I part of this industry or not? What even makes something an "important" industry vs. a non-important industry?
It seems odd how you point to "car/power plant/pacemaker" examples when few people with Microsoft GitHub accounts work in real-time systems, much less ones which risk human injury or death.
My business works with P.O.s, contracts, wire transfers, one-on-one interactions, customer knowledge of my 25 years of working in this field, and my ability to vet my customers.
That's where the "trust me" comes from, not bro-dom, not Microsoft with its long history of security failures.
I didn’t say you aren’t in an important industry.
I said if you are in an important industry, a single password should not be the only measure stopping malicious packages to be distributed on your behalf.
Your customers can trust you all they want, but can they trust packages are actually coming from you or a compromised account due to a leaked password.
I said if you are in an important industry, a single password should not be the only measure stopping malicious packages to be distributed on your behalf.
Your customers can trust you all they want, but can they trust packages are actually coming from you or a compromised account due to a leaked password.
edit, I can't read..
Gitlab's currently on fire, don't worry about it. https://status.gitlab.com/
Also, really, nowadays everything should be MFA or SSO backed with MFA.
Gitlab's currently on fire, don't worry about it. https://status.gitlab.com/
Also, really, nowadays everything should be MFA or SSO backed with MFA.
I will say a status page that gives out red flags at least makes me trust it more.
The AWS status page might as well be static until there is massive outrage on the internet that shows it is completely down, then a single green light will turn yellow or red after HR or Marketing have confirmed that there is no hiding the outage.
The AWS status page might as well be static until there is massive outrage on the internet that shows it is completely down, then a single green light will turn yellow or red after HR or Marketing have confirmed that there is no hiding the outage.
For the record, I don't like it either.
I use generated passwords and I check the URL before c+p'ing my password, what do I gain with it?
I use generated passwords and I check the URL before c+p'ing my password, what do I gain with it?
A lot less than what your average 'I just reuse the same password on a million sites' or your average 'my password is "iloveyou8", you see, the 8 makes it secure!"' user gains from 2FA.
But it's not nothing.
If you get phished and enter both your password and TFA in a scam site, they can log in as you, but they will not be able to log in as you later on, and (presumably, if github configured their stuff correctly) them _changing_ your settings (either updating TFA or removing the requirement to use TFA) is either not possible without _another_ attempt to phish you, or will result in you at least knowing e.g. because you receive an email from them. In contrast if they have your password and that's all that is needed to log in, they can now log in as you for however long until you change your password, and you won't know.
Similar benefits apply if your hardware is compromised due to a keylogger. Or, much more plausible, some tool is watching your clipboard. Which _will_ see the password, but _will not_ see your TFA unless you're also copy pasting that on the same device.
If the device that stores your generated passwords is itself compromised and you store your 2FA stuff elsewhere (a good general principle!) then it helps _quite a lot_. Trying to 'fake it' without 2FA is quite complicated; you'd need to store half of your password on one password vault and the other half on another and combine them by hand.
It depends a bit on your theory about how security is best done. if you ascribe to the swiss cheese model (where you layer quite a few slices of swiss cheese on top of each other with the aim that whilst each slice has holes, the stack does not have any holes), then these are quite a few added slices.
But it's not nothing.
If you get phished and enter both your password and TFA in a scam site, they can log in as you, but they will not be able to log in as you later on, and (presumably, if github configured their stuff correctly) them _changing_ your settings (either updating TFA or removing the requirement to use TFA) is either not possible without _another_ attempt to phish you, or will result in you at least knowing e.g. because you receive an email from them. In contrast if they have your password and that's all that is needed to log in, they can now log in as you for however long until you change your password, and you won't know.
Similar benefits apply if your hardware is compromised due to a keylogger. Or, much more plausible, some tool is watching your clipboard. Which _will_ see the password, but _will not_ see your TFA unless you're also copy pasting that on the same device.
If the device that stores your generated passwords is itself compromised and you store your 2FA stuff elsewhere (a good general principle!) then it helps _quite a lot_. Trying to 'fake it' without 2FA is quite complicated; you'd need to store half of your password on one password vault and the other half on another and combine them by hand.
It depends a bit on your theory about how security is best done. if you ascribe to the swiss cheese model (where you layer quite a few slices of swiss cheese on top of each other with the aim that whilst each slice has holes, the stack does not have any holes), then these are quite a few added slices.
Thanks. I like the resistance against reading your clipboard, and I assume this is possible as a non-root application on Linux such as a steam game that I started.
Phishing awareness I have with the exception of dumb moments.
TFA on two devices I have as well but most my techyish colleagues actually don't, especially not for stuff that's easily done on the phone such as banking/crypto :-/
Phishing awareness I have with the exception of dumb moments.
TFA on two devices I have as well but most my techyish colleagues actually don't, especially not for stuff that's easily done on the phone such as banking/crypto :-/
[deleted]
> If you didn't configure 2fa yet, the time has come to do it.
The time has come to ditch GitHub.
A while ago I barely managed to create an account using an email alias that worked (instead of providing my actual email). Within minutes GitHub deleted my account for some reason. I suspect it’s because I used email alias, but I really have no idea why.
The time has come to ditch GitHub.
A while ago I barely managed to create an account using an email alias that worked (instead of providing my actual email). Within minutes GitHub deleted my account for some reason. I suspect it’s because I used email alias, but I really have no idea why.
Why is it time to ditch GitHub? Are you morally opposed to 2FA or using a valid email?
Not the OP, but I am opposed to the forced use of 2FA by GitHub for three reasons:
1) They are my repos. I should get to decide the appropriate level of security.
2) 2FA is often used as a pretext for identity harvesting which are then abused for other purposes.
3) If there is account recovery via email then the whole thing is a charade anyway.
1) They are my repos. I should get to decide the appropriate level of security.
2) 2FA is often used as a pretext for identity harvesting which are then abused for other purposes.
3) If there is account recovery via email then the whole thing is a charade anyway.
> 2) 2FA is often used as a pretext for identity harvesting which are then abused for other purposes.
Okay, but there are many options, like TOTP code generators, that do not even require the internet to work.
> 3) If there is account recovery via email then the whole thing is a charade anyway.
You can disable all account recovery options in Settings.
Okay, but there are many options, like TOTP code generators, that do not even require the internet to work.
> 3) If there is account recovery via email then the whole thing is a charade anyway.
You can disable all account recovery options in Settings.
Agreed with 2 in general, and it frustrates me endlessly, but github offers & encourages TOTP & U2F authentication which are privacy-preserving.
> They are my repos.
GitHub is not forcing you to use 2FA to store your repos elsewhere. Just to interact with their website.
> I should get to decide the appropriate level of security.
People are really bad at deciding the appropriate level of security.
GitHub hosts a lot of very important projects that have impact in the real world. Forcing people to use the bare minimum to keep that environment relatively secure is probably not a bad idea.
That way when you set your password as "batman123" and are given commit access to some obscure project that is included as a dependency in 1000 other projects, your account is much less likely to be taken over as a means of pushing a malicious commit.
GitHub is not forcing you to use 2FA to store your repos elsewhere. Just to interact with their website.
> I should get to decide the appropriate level of security.
People are really bad at deciding the appropriate level of security.
GitHub hosts a lot of very important projects that have impact in the real world. Forcing people to use the bare minimum to keep that environment relatively secure is probably not a bad idea.
That way when you set your password as "batman123" and are given commit access to some obscure project that is included as a dependency in 1000 other projects, your account is much less likely to be taken over as a means of pushing a malicious commit.
1) They are my repos. I should get to decide the appropriate level of security.
How is an "email alias" (whatever that is) not a valid email address?
An email alias is typically an email address that redirects to your true email address. Which is conceptually fine, but the OP hasn’t shared specifics so for all we know they used a temporary email address from a service that spammers use.
And GitHub does have a spam problem (if you haven’t dealt with it yet, consider yourself lucky). Just the other day someone opened an issue in one of my repos and in less than a minute two spam accounts replied with links to download malware. Fortunately I caught them right then and there, deleted the comments, and reported the accounts to GitHub which banned them soon after.
And GitHub does have a spam problem (if you haven’t dealt with it yet, consider yourself lucky). Just the other day someone opened an issue in one of my repos and in less than a minute two spam accounts replied with links to download malware. Fortunately I caught them right then and there, deleted the comments, and reported the accounts to GitHub which banned them soon after.
Fair enough. I hadn't considered the spam problem. No, I haven't really encountered it, but then I don't really use GitHub very much either.
2FA is superfluous if you’re using high entropy passwords stored in a password manager that incorporates phishing protection mechanisms (e.g. refusing to fill / warning when domains do not match).
2FA is still useful if the password is leaked.
Not if the 2FA seed is leaked as well.
I don't use the deadbolt on my front door, I just close it.
If someone can open the handle they can kick down the door as well.
If someone can open the handle they can kick down the door as well.
Until the password manager is hacked/leaked. See: lastpass breach.
Protecting the security of multiple devices is much easier than maintaining, rotating, and securing cryptographically secure passwords. Ideally, as with most things in security, do both. There’s no real reason to eschew 2FA other than “I hate typing in a code sometimes.”
Protecting the security of multiple devices is much easier than maintaining, rotating, and securing cryptographically secure passwords. Ideally, as with most things in security, do both. There’s no real reason to eschew 2FA other than “I hate typing in a code sometimes.”
> Until the password manager is hacked/leaked. See: lastpass breach.
Certainly. If we're considering password manager compromise, it's also reasonable to include compromises of all 2FA mechanisms. Users can often have 2FA creds phished just by calling them ("something is wrong with your account, please read the 2FA code to verify your identity"). Sure, you and I wouldn't fall for this, but there are plenty of retirees out there who have. At that point, neither 2FA nor password manager would save them. You could compromise the password manager by social engineering ("add evilsite.ru to the allowed sites") or even by supply chain attacks (create a build that permits evilsite.ru). Since supply chain attacks are a reasonable hack against password managers, the same could be said about 2FA apps.
Consequently, we don't get anywhere productive in this discussion by assuming software compromise into the threat model.
Certainly. If we're considering password manager compromise, it's also reasonable to include compromises of all 2FA mechanisms. Users can often have 2FA creds phished just by calling them ("something is wrong with your account, please read the 2FA code to verify your identity"). Sure, you and I wouldn't fall for this, but there are plenty of retirees out there who have. At that point, neither 2FA nor password manager would save them. You could compromise the password manager by social engineering ("add evilsite.ru to the allowed sites") or even by supply chain attacks (create a build that permits evilsite.ru). Since supply chain attacks are a reasonable hack against password managers, the same could be said about 2FA apps.
Consequently, we don't get anywhere productive in this discussion by assuming software compromise into the threat model.
I don't really understand the point you're making. Certainly any method can be compromised - I'm not claiming that 2FA can't. In fact, the post you are responding to says ideally, do both. This is sort of why defense in depth is a concept. Even in your example, the 2FA compromise also involves first compromising the password/login credentials.
> In fact, the post you are responding to says ideally, do both
Right, I said that even if you do both, both can still be compromised simultaneously and independently. The discussion is more productive if we assume that the password manager can be made secure in the same way that 2FA can be made secure.
This returns to my original argument that “assuming a secure password manager with phishing protection, 2fa+password provides no more security than a high entropy password.” Before we go there, this also includes the unstated assumption that the website also leaks only useless information to an attacker (salted hashes that would require centuries to brute force).
Right, I said that even if you do both, both can still be compromised simultaneously and independently. The discussion is more productive if we assume that the password manager can be made secure in the same way that 2FA can be made secure.
This returns to my original argument that “assuming a secure password manager with phishing protection, 2fa+password provides no more security than a high entropy password.” Before we go there, this also includes the unstated assumption that the website also leaks only useless information to an attacker (salted hashes that would require centuries to brute force).
Why even bother with passwords in the first place, they can just be social engineered or phished too!
> There’s no real reason to eschew 2FA other than “I hate typing in a code sometimes.”
Not even that is a good reason for someone who uses a password manager. Most of them today allow storing your 2FA key and auto-fill them.
Not even that is a good reason for someone who uses a password manager. Most of them today allow storing your 2FA key and auto-fill them.
I don’t have important stuff on GitHub, so for me the additional effort of 2FA is not worth it. I’ll ditch GitHub.
Well, I guess they don't lock it immediately and you can make it a little easier with keepass.
Is it really ditching it if you weren’t using it to start with, lol.
I don’t like that Spotify asked me for a valid credit card, so I’m cancelling my 30 day free trial. I don’t listen to much music anyway.
I don’t like that Spotify asked me for a valid credit card, so I’m cancelling my 30 day free trial. I don’t listen to much music anyway.
It’s stupid to force ppl
To use. Using 2FA should be done, it’s great, it should DEF not be mandatory. Very bad product decision
I wonder if they fear reputational damage from being a weak link in (future) supply chain attacks.
PS: I didn't see this news, so posting it, sorry if I'm slow