Passwords begone: GitHub will ban them next year for authenticating Git operations Microsoft's GitHub plans to stop accepting account passwords as a way to authenticate Git operations, starting August 13, 2021, following a test period without passwords two-weeks earlier. The planned change does not affect the ability to login to a GitHub account in a web browser with a username, password, and perhaps a …
Most problems with passwords fall into three categories:
1) Reuse of passwords.
2) Short and easy-to-guess passwords like yourefired or MAGA2020!
3) Lack of encryption/salt on the server side.
Tokens eliminate 1) and 2) at least, and if the token is exposed due to 3), it can easily be replaced. So it is an improvement.
LOL!
It's far easier to use certificate with Windows than Linux. First, they are stored in a single place easily accessible and manageable instead of being scattered everywhere in the file system, to be managed manually. The only problem is when using idiotic languages and libraries which can't access the certificate store (or applications like Firefox who believe using only their own one is "clever").
Generating certificates with a Windows CA is very simple, especially if you use templates, and enrolling can be even automated (or you can request them through a web interface).
That said GitHub would just need to deliver client certificates to users, and could use whatever it likes to generate them, for example the "simple" and "user friendly" OpenSSL command line interface.... then uses will be free to store and use them as they prefer.
So how does it work if you have multiple devices using a connection.
I can think of when this could really cause a problem, for me at least.
a) Company has a paid-for github site to store source on, allowing 'work from anywhere'
b) each embedded device I'm using for development has one or more copies of a github repo [sometimes different branches pre-checked out for comparison, let's say] and I'm constantly doing git pull/push from these various repos in various places to sync up with the online repo
c) I can type in my password, which is complex and long, fairly easily. and I don't store it anyplace. My fingers do the motions accurately at least 90% of the time. It's over 10 characters long, has numbers and symbols in it, etc..
So, what must I do *NOW* - copy/pasta a token from "someplace" every time I use git? STORE THE TOKEN(S) ON EACH DEVICE??? (*NO*!!!) This could end up creating a very unpleasant experience, effectively *PUNISHING* those of us who use proper passwords, because a *FEW* do *NOT*. it also may force updating the git software, WHICH! YOU! MIGHT! NOT! WANT! TO! DO! FOR! EMBEDDED! SYSTEM! DEVELOPMENT!!! You know, STABLE KERNEL and NOT having to deploy KERNEL/USERLAND UPDATES for air-gapped equipment because "some package" was updated on a dev system and NOW the compiled executables won't run... or a behavior changed... or something like that. yeah even Linux has package-dependency-hell to deal with, and when package 'a' drags in 'b' 'c' 'd' etc. and/or forces updates, it COULD (potentially) end up being a mess. And I really did NOT want to include 'selected .deb files' on the USB drives to update firmware, and have to test ALL of the NEW OTHERWISE-UNNECESSARY 3RD PARTY edge cases to avoid midnight phone calls. yeah I like to TEST before deploying,.
I don't use GitHub but I have difficulty believing that the standard way is not to use SSH keys, just like with every other non-local Git repository out there.
Of course you are still free to choose whichever passphrase you want for your SSH key, or even a hardware device if that's your preference.
This post has been deleted by its author
I have always found SSH keys the most convenient to use with Git operations, whether on GitHub or anywhere else. First of all it's easy to setup, only requires the SSH password to remember instead of username/password combo, and it integrates well with automated services (e.g. CI/CD), which can use an SSH daemon to securely use the stored password for the SSH key.
I had to look at the token-based approach in some depth while writing about this topic a while ago for Hackaday, and I'm not convinced that I would ever use it. Especially the part where you have to lug this (hardware) token around and remember the PIN for it seems like a bother. Plus I'm not really seeing how it'd make integrating with services any easier.
I have always found SSH keys the most convenient to use with Git operations, whether on GitHub or anywhere else
This may be true until you are working with multiple embedded devices, and workstations, and have to either AUTHENTICATE EVERY SSH KEY for EVERY DEVICE [and then make sure you erase them when that device gets turned into a test platform (where you still need github access to update it) and THEN suddenly ends up at a customer site for evaluation before you can say "OH CRAP NO!". So even if you erased the source repos in time, you still would need to deal with those ssh keys in ~/.ssh/ ...
and... where can I safely store this alphabet-soup token such that it can be *EASILY* copy/pasta'd onto ANY device... ? yeah, thought so. And don't say 'USB stick' - some of the embedded devices will have all of the ports occupied already, for devices they control, at least for the stuff _I_ am working with.
And access to YOUR login from "any machine" (remote workstations and embedded devices included) is a necessary feature sometimes. This way, anyone (or any device or workstation) needing a 'git clone' could get a quicky copy of the online repo without jumping through unnecessary hoops. Cheapo paid-for version of github limits the number of collaborators, after all...
So many potential problems with devs like me, and yet independent devs or devs with individual logins ONLY dedicated to a particular company's stuff [and it's never "accidentally deployed"] won't have problems with this sort of thing.
the only thing WORSE than this would be 2FA requiring a phone or e-mail to your home e-mail address [when you're on site and not having access to it and you don't want *THEM* having your cell phone number] in addition to user/pass and/or tokens.
> AUTHENTICATE EVERY SSH KEY for EVERY DEVICE
USE THE SAME FUCKING KEY
> and then make sure you erase them when that device gets turned into a test platform
And then remove the corresponding public part from the server when you're done with it. You can leave the private key in your devices; it is now useless.
I feel that I shouldn't need to be mentioning this. Perhaps a short course on information security wouldn't go amiss, if I may suggest.
Maybe I misunderstand? What possible benefit would you gain from using multiple key pairs when the end goal is to authorise access to your code repository? I would only consider that if I needed to (weakly) authenticate or if there was a concern about compromise of one single device (where you only need to disallow that one key pair).
Neither is the case in the scenario you described. If you were intending to use this in production then it would be a different matter but that doesn't appear to be the situation.
So it is far from OBVIOUS to me, having had proper academic schooling and some hands-on experience in information security.
This is a good question that I think can be best answered as... for a while. I think you're seeing the end game pretty clearly.
You store stuff in your home, does your realtor keep and cut your only keys? Of course what you put on GitHub isn't yours alone anyways, so why should the keys be yours? What amazes me is how easy it is to run your own Git server in the year 2020, and it has to be if it's Git, yet people just keep hoping on commercial alternatives. The whole thing is turning into "Get the next great Microsoft Office 20xx today!", which boils down to you didn't know you needed it, until you were told you did.
GitHub/GitLab/etc. == Open Source Party Lines (just hope no one cuts your line)
Hmm, this is what I was worried about. Luckily I only really use GitHub as yet another remote mirror (along with Bitbucket and GitLab) via "git cvsimport" but it is frustrating to see Microsoft demonstrate their same old crap over and over again. Actively avoiding corporations is getting boring.
I'd bet that SSH keys will stick around, simply because they are ubiquitous in git usage and definitely not insecure -- but I suspect they'll start encouraging "sk"-format keys stored on U2F hardware tokens sooner or later, to prevent attackers stealing keys off client disks or out of client memory. (SK keys are new in OpenSSH 8.2+: it's the only hardware token mechanism I've ever found to be in any way usable. As long as both client and server are new enough -- a requirement, since this is a new key type -- I've found it as reliable as ordinary on-disk keys, something I could never have said of the old CCID-backed PIV or GPG-based nightmares.)
Constantly trying to make it "safer" to be stupid by implementing point fixes to recognised poor practice after the fact doesn't prevent folks being stupid when using the fix. If the approach is used for long enough, there'll be no more point fixes possible and quite likely the things protected will be so surrounded by controls that they'll be unusable. And the folks who act stupidly will continue to do so.
Just as an example of the kind of point fix I mean, our commercial telephone banking now disallows transactions over a randomly varying amount unless we accept a text message on a mobile phone for confirmation. Pointing out that a text message is entirely insecure and can be spoofed cut no ice at all with even a moderately senior manager. Pointing out that the assumption that everyone has a smart phone to hand is also bo**ocks cut no ice either. They're also trying to enforce voice recognition for authentication, despite quite a lot of authoritative research over the last few years proving it's fragile and breachable.
My bank requires me to use SMS TFA every time I log in to their website and again if I make a payment from their website. They also log me out after 90s of inactivity. Not to mention randomly when I'm using my card on other websites, even ones I use on a regular basis. It is a total pain in the arse, especially having to re-authorise every payment once I'm already on their website.
I have pointed out to them that SMS is not secure, there are numerous groups who could intercept it and if I was mugging somone I'd steal their phone with their wallet making it moot. All they do is repeat the security lie, but louder. It's like dealing with my geriatric parents.
I had the same issue. I contacted them to inform them I lost my phone. When they asked for a replacement number I told them I don't have one and that I no longer use phones. They looked at me strangely but it is not like they can leave the "stolen" number in their database. XD
Their TFA then defaulted to email (again, not exactly secure) but at least I can avoid the creepyness of phones (and emails can be scripted).
It's commonplace. Most banks have *ancient* systems, and this is just one of many ways that shows.
If you want ridiculous, until last year the Coventry had a scheme where you had an eight-char password, uppercase alphanumerics only, changeable on request -- they posted you a form with eight boxes in it which you filled out and posted back, and then a few days later the password was changed. This was obviously grossly insecure so they pasted other security challenges over the top of it over time (and lately have replaced it entirely).
I bet this is because the password in question was an actual mainframe account password of some sort, changeable only from an operator console. It had that smell. (This year, they changed to allowing really long passwords, and better yet passwords with no stupid restrictions on what characters must be present, so I can just use the result of a yubikey's HMAC-SHA1 challenge-response as the password. Finally.)
At least in the US, only a few of the biggest banks maintain their own online banking, most buy an online solution from a turnkey vendor and skin it to their liking. Unless you get the ear of the C suite and think they can hire and retain enough talent to handle online banking, your complaints fall on deaf ears.
80%-20% rule. 80% of the population are of significantly limited cognitive function, and not to be trusted with sharp objects or life and death decisions. The remaining 20% struggle to keep everyone alive and functioning, whilst constantly under assault by those very semi-undead zombies surrounding them, who mistakenly believe that they understand what they are about, and try to 'help improve security' by random acts of self-defeating frippery.
It has ever and always been this way.
Although despair isn't a universal reaction to this fact, it is a common one.
As my Pointy-haired Boss decreed in a meeting back on the 9th of September 2005, "and starting today, all passwords must contain letters, numbers, doodles, sign language and squirrel noises." So, this is not a new thing, but Squirrel Noises is definately the way to go.
I'm at an age where remembering a million passwords really doesn't work, Lastpass is freaking out at me for repeating and reusing and those twat companies that believe they can create some "not invented here" dumbass rule - thats you lg.com. and just google "worst password rules"
Give me a token anyday, please no arsing about with eminently knickable certs...
rant over
I've been using KeepassXC (the non-mono one) lately. works pretty well, and is still being maintained last I checked. I have a nice long true 'pass phrase' that I make mistakes typing in a lot, but fortunately there's an eyeball button so I can see what I just typed... and then correct it.
...an odyssey that began in 1995 with the introduction of "Microsoft Passport.", marked also by the "Internet Tidal Wave" memorandum from B Gates.
Passport got massive pushback at the time, because of reluctance to hand authentication to a company like (now) Google or Facebook ....
#2:27 18-12-20#
In the systems that I design, unless there is a compelling reason not to, users can have however many passwords they want, each username / password combination with its own set of permissions.
This approach makes it trivial to incorporate tokens (just generate a random password for the user), and it also:
* Lets the user “modulate” their permissions (sort of like using “su” when you need to rather than being logged in as root all the time)
* Makes it trivial to implement panic passwords (if your requirements contemplate the possibility of users acting under duress)
* Is practical for users who move between different keyboard layouts. E.g., they can have one password with a £ + @ and a similar one with # + " instead.
* They can use a longer, more complex password when there is a risk of shoulder surfing and a simpler one when in a safe environment.
* Etc.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
