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?
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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'm not a rust expert by any means, but I believe there's a problem with lifetimes. There are many ways to implement double-linked lists (think C++ smart pointers), but when you try to squeeze performance and use references, then it's a fight against borrow checker, which ends with the need to use unsafe rust.
Borrow checker is just a checker, which ensures that programmer doesn't write obviously wrong programs. It's obviously wrong to create cyclic references, even in a language with garbage collector, such as JavaScript. Why you need to fight with checker?
Regarding the borrow checker, what you say is not correct. The borrow checker's rules are stricter than absolutely necessary. It is designed to reject all invalid programs, but it also rejects some valid programs.
Yes, rust compiler team improves borrow checker from time, to allow more valid programs to pass the checker. However, in practice, it's always possible to use unsafe code to do the job, and then build a safe façade for it.
In this particular case, borrow checker does it job as designed. So, why to fight it?
Some GC detects cycles, some not (reference counting is example of GC which does not), but even those which detects cycles, may not able to detect all of them or it can be expensive as, for example, in typical Mark&Sweep GC, because it may require to stop the world to perform GC, which is unacceptable for system programming languages, like C, C++, Rust.
When tree will go out of scope, their nodes memory will be reclaimed automatically ("dropping" in Rust terms) by automatic garbage collector built-in into compiler: `drop(root)->drop(leaf_a),drop(leaf_b)`. However, if leaf will have reference to its parent, then an infinite loop occurs: `drop(root)->drop(leaf_a)->drop(root)->drop(leaf_a)...`
The solution is to use an alternative automatic garbage collector instead of compiler built-in: arenas, RC with weak references, or Mark&Sweep GC. Arenas have better performance, because they drop all nodes at once. The easiest way to quickly implement an arena in safe Rust is to use vector (array) of nodes and used indices instead of direct references.
You've said it would be obviously wrong "even in a language with garbage collector, such as JavaScript." But, obviously, most modern GC can handle cyclic references just fine.
But even languages with Tricolour Mark&Sweep GC, which handles cyclic references just fine, it's still possible to make memory leak via a dangling reference to a node in a complex cross-linked graph, because language and GC allows that.
Rust by default forbids cyclic references, by forcing to use trees, which completely avoids the problem.
Rust uses double linked lists, they are not harder to implement in Rust than in any other language. Moreover, built-in borrow checker will help to implement them properly, without memory leaks or use-after-free. What is your point?
While authelia is quite cool "infra-as-code" tool, since you have your entire configuration in yaml form, for those not willing to spend a few evenings configuring SSO, there is authentik [1] which features management UI.
Offers similar feature set, also self-hostable, but most importantly - simple to set-up. I've spent 8h on authelia deployment, where 30 minutes in authentik would be sufficient. But both are good options, pick what you prefer.
In more "formal" discussion environments than an Internet discussion thread, sometimes a "proposal" or statement made by someone will be met by someone else giving their support of said statement by stating "I second that", meaning they're the second person in the room to support the statement verbally aloud.
TLDR; They're throwing their support of the OP's statement into the ring.
> "do you mean authentik is much easier to setup?"
I do believe from the context of the rest of their comment that's exactly what they mean to say.
When performing forensic analysis, metrics don't usually help that much. I'd rather sift 2PB of logs, knowing that information I'm looking for is in there, than sit at the usual "2 weeks of nginx access logs which roll over".
Obviously running everything with debug logging just burns through money, but having decent logs can help a lot other teams, not just the ones working on the project (developers, sysadmins, etc.)
What's the point of having your 2FA codes synchronized across all your devices?
Isn't it in the name "TWO FACTOR"? It's supposed to be a separate device and ability to "across devices" comes as an anti-feature for me.
1) If you're not using password manager, then you're probably using same password everywhere, including your 2FA app.
2) If you're storing your 2FA codes in your password manager, then it's not really a 2nd factor. It helps against password leaks from services, not from a password manager leak.
Ability to synchronize encrypted backup is a different story.
It's "Two Factor Authentication", not "Second Factor On A Single Device You Always Have On Your Person Authentication".
That second factor needs to be separate from the originating authenticating service, not that it has to be on a single device hidden away kept in a safe, or on your wrist, or in your pocket. It could be a single device [a server] running bitwarden and you're viewing it through a browser on your <whatever>.
Not everyone wants to follow every single recommendation from a data security perspective, and it becomes an anti-pattern when laymen start using workarounds to not have to comply with the safety recommendation of the week.
Having it integrated with a password manager is less secure than having it as a separate app in a separate device, but it makes it so much easier for the average person that they're more likely to actually use it.
In a vacuum, yes, you're right. It's not as secure this way. I wouldn't use that for something hyper-sensitive like classified systems. But as a system, "less secure but widely used" beats "more secure but most people avoid using it whenever possible".
It's like with the NIST recommendation against regularly rotating passwords. In an ideal world, it's a great ideal to require new passwords frequently. In this world, it only makes people pick bad passwords and append the date or serial number to it. As a system, it's more secure to require strong passwords and then leave them alone until/unless you suspect they've been compromised.
It’s really two step auth. Basically the point is that it defeats password spray attacks.
Higher assurance authenticators need more than TOTP. Usually that means adding a knowledge component (ie pin), challenge/response, a physical token, biometric or all of the above.
It means you are providing two factors, not necessarily that you only have two factors.
There are benefits to this. I've left my phone at work, and would have been SOL, except I have a tablet that never leaves my home which can also provide my second factor.
Spending 1 minute setting up 2FA is really not a big deal.
[1] https://github.blog/news-insights/product-news/raising-the-b...