GitHub to require two-factor authentication for code contributors by late 2023 GitHub has announced that it will require two factor authentication for users who contribute code on its service. "The software supply chain starts with the developer," wrote GitHub chief security officer Mike Hanley on the company blog. "Developer accounts are frequent targets for social engineering and account takeover, and …
> But now seeing it is Microsoft, they'll use their own app.
>
> If it was based on standard TOTP, then there's no data to mine.
Last I checked, Microsoft Authenticator *is* TOTP based, so you can easily use Authy, Google Authenticator or a python script instead.
Github don't just support TOTP 2FA anyway - I use a U2F key as a second factor, with TOTP set up as a fallback
Microsoft would have to scrap an awful lot of the existing 2FA implementation to turn it into a data mining operation.
I'm all for cynicism, especially about data collection, but this isn't one of those times
I did some digging yesterday when I first saw the news of this. From what I can see TOTP is one of the main options. Github are pushing their phone app as the preferred TOTP solution, but I don't see any reason why you would have to use it.
I installed "oathtools" (sudo apt install oathtools) to see how that worked, although I haven't tried it with Github yet however. Oathtools uses HMAC by default, but has a TOTP option.
Apparently once you have registered your key with Github you give oathtools your key and it generates a second key which basically amounts to a series of one time and time limited passwords. You then use that to log into Github. Your PC's clock obviously has to be reasonably correct for this to work, as the one time password uses the current time as one of its inputs.
The intent of this is to prevent replay attacks where someone gets a copy of your password and reuses it over again later. With TOTP your "password" stays on your PC and you just use an encrypted one time version of it instead.
Here's an example:
oathtool --totp 0123456789abcdef
197691
In the above "0123456789abcdef" is your secret key (in hex) which you register with Github and "197691" is an example of the one time password you use to log in with. Each time you run it you will get a different output.
I haven't tried this yet (I'm in no rush to be one of the guinea pigs) but from what I can see it should work. I will probably end up using zenity to turn the command line program into a simple GUI app which I would launch with a click from the desktop.
The whole thing could probably use a Register article showing how the best options are done as I found the Github explanation to be convoluted and difficult to understand. Github's explanation is very "Microsoftian" in that it only really makes sense after you've spent time figuring it out based on other sources.
There's much, much, much more to Github than just repo hosting.
The interface provides project management, CI etc etc etc.
But, the biggest reason for using Github tends to be discoverability - unless you're already a big project, you'll likely get much more use and many more contributors by being on Github. Especially for small drive-by fixes (almost no-one's going to create an account on your server to fix a small UI bug, but they might chuck a quick pull request, or at least an issue report in on Github).
Although it's not generally what you think of as social media, it has many of the same effects - you derive some benefit from being where the users are.
I host my own git repos for various things, but it really is an incomplete alternative for many projects.
I'm the same, GitHub is good for making a project discoverable.
I run my own instance of Gogs locally for hosting private repos. Handy whilst working on a project before pushing it to GitHub to make it public.
It also supports mirroring so you can make a local copy of a GitHub (or any other git repo) and it will keep it in sync.
I often use github to synchronize development on multiple (often embedded) devices, and with multiple repos. Having to use that cert-like thing instead of a password is difficult ENOUGH to implement on my end, but I did it anyway and now it does NOT slow me down nor require having it in a PLAIN TEXT FILE.
But if they make it even MORE inconvenient, I'm likely to recommend that paid repos be moved ELSEWHERE. And I'll move MY OWN repos as well.
There are times when I have no easy access to my PERSONAL E-MAIL for a 2FA thing. WORSE, I *REFUSE* to give THEM a CELL PHONE NUMBER (it's almost always off anyway). And using a different git login for 'occasionally in an office' vs 'at home' is EVEN WORSE (and there are limits to how many logins have access to a paid repo without paying EXTRA).
And how would you type in such a code when using 'git pull' or 'git push' ANYWAY ??? It should ONLY be optional to stick 2FA on somet6hing that's ALREADY secure enough.
I have noticed some level of it on the web site alredy though. if I have to do admin stuff I use the boss's login rather than my own, and I have to have him on slack to give me the stupid code so I can finish logging in. It's inconvenient but via the web interface it's plausible, I suppose...
For 'git pull' and 'git push' I have the 'cert like' password stored in an encrypted file. To access it I type in the password I would have otherwise used at a prompt from a shell script that decrypts it and pastes it to the clipboard. This somewhat conveniently lets me access 'git pull' and 'git push' over ssh as well. So I worked around their little inconvenince. AND! I! DO! NOT! WANT! THIS! GETTING! ANY! WORSE! IN! THE! FUTURE!!!
The last t6hing *I* need is ANAL RETENTIVE BUREAUCRATIC 'ONE SIZE FITS ALL FOR EVERY BRICK IN THE WALL' UNNECESSARY INCONVENIENT CRAP GETTING IN MY @#$% WAY!!!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
