Live data from Hacker News

Git password authentication is shutting down

github.blog

11–20 of 353 posts

Re: Git password authentication is shutting down

#11
post #6

I have a noob question: what's the right way to use these tokens without password managers? I believe Github recommended assigning it as an environment variable in docs related to this deprecation, but isn't a (managed) server free to log the output of `echo $token`?

Use SSH and GPG to authenticate and sign commits, it's easier and quicker. If you're doing something that needs a token use a GitHub App Token:

https://docs.github.com/en/developers/apps/getting-started-w...

Re: Git password authentication is shutting down

#12
post #6

I have a noob question: what's the right way to use these tokens without password managers? I believe Github recommended assigning it as an environment variable in docs related to this deprecation, but isn't a (managed) server free to log the output of `echo $token`?

If there's a managed server you don't trust, it's unsafe to put anything that authenticates you to GitHub there, because it can (e.g.) modify the git command to push malicious code.

For a semi-trusted machine (e.g., you want to "git push" to work-related OSS from your work desktop, but you don't want your work HR/IT departments to have full access to your GitHub account if they decide they want it), make a new SSH key and configure it as a read/write deploy key for that one repo. This workflow is primarily intended for automation, but it's reasonable for this sort of interactive use as well.

https://docs.github.com/en/developers/overview/managing-depl...

Re: Git password authentication is shutting down

#13
post #2

I wonder how many old, forgotten systems there are out there that pull from Github with a password. Brownouts are a smart way to try and weed those out, but there are going to be residual requests. I wonder how many.

Looks like they've been doing them for about a year, but stragglers are a guarantee!

Re: Git password authentication is shutting down

#14
post #7

Embrace. Extend. Extinguish

Passwords are probably one of the worst things to happen to our field as a whole (phishing, password managers, etc. are the results of their ubiquity), so efforts to remove them are probably not part of some Microsoft plan to kill open source. This change is a good thing.

Re: Git password authentication is shutting down

#15
post #6

I have a noob question: what's the right way to use these tokens without password managers? I believe Github recommended assigning it as an environment variable in docs related to this deprecation, but isn't a (managed) server free to log the output of `echo $token`?

One probably has to assume at least some level of control of any system where there's access to secrets where they're necessary for production processes.

But if you aren't confident of it, then at least that token only has access to a repository, and can't be exfiltrated to let somebody log in and really mess with your user account or your organization.

(All that said: I'd recommend a single-use, minimally privileged SSH key over an access token, just because that workflow's what you should be using on a desktop too.)

Re: Git password authentication is shutting down

#16
post #5

tldr Git SSH protocol will still support authentication via username:password but in this case, the "password" can no longer be your Github Account password, but it can be a Personal Access Token. So no need to panic if you've been using a build system or other tool that authenticates with username:token instead of a SSH key.

TLDR? The article was three sentences!

Re: Git password authentication is shutting down

#17
post #10
post #9

Earlier quoted context omitted.

They do it to prevent passwords, which allow access to privileged things like account settings, from being stored (and thus subject to being accidentally leaked). It doesn't matter how long your password is if your password is in a text file with bad chmod permissions to people who shouldn't have it. An access token, at least, limits the blast radius.

Ah get it. They don't want the password to login on github to be the same as the one you store on a text file. Makes sense. But it is still Baby-sitting

What you describe as "baby-sitting", I would call "encouraging users to fall into the pit of success."

Many, many GitHub users are not professional software developers, and many more than that are not security-minded users at all. Small incremental improvements like this are a kind of defense in depth, and it is valuable.

Re: Git password authentication is shutting down

#18
post #10
post #9

Earlier quoted context omitted.

They do it to prevent passwords, which allow access to privileged things like account settings, from being stored (and thus subject to being accidentally leaked). It doesn't matter how long your password is if your password is in a text file with bad chmod permissions to people who shouldn't have it. An access token, at least, limits the blast radius.

Ah get it. They don't want the password to login on github to be the same as the one you store on a text file. Makes sense. But it is still Baby-sitting

And we have fifty years of software development history to prove we need this kind of babysitting. It’s a pain one time and then you realize it wasn’t hard to do and start doing a better practice out of habit.

Re: Git password authentication is shutting down

#19
post #10
post #9

Earlier quoted context omitted.

They do it to prevent passwords, which allow access to privileged things like account settings, from being stored (and thus subject to being accidentally leaked). It doesn't matter how long your password is if your password is in a text file with bad chmod permissions to people who shouldn't have it. An access token, at least, limits the blast radius.

Ah get it. They don't want the password to login on github to be the same as the one you store on a text file. Makes sense. But it is still Baby-sitting

Eh, I think everyone stands to benefit when a service increases their security standards in a reasonable way. Fewer account recovery support requests for them, fewer footguns for inexperienced users of theirs.

Do you consider password length requirements baby-sitting?

Post reply on HN