[HN Gopher] Introducing fine-grained personal access tokens for ...
___________________________________________________________________
Introducing fine-grained personal access tokens for GitHub
Author : tarebyte
Score : 152 points
Date : 2022-10-18 15:36 UTC (7 hours ago)
(HTM) web link (github.blog)
(TXT) w3m dump (github.blog)
| 0xbadcafebee wrote:
| If you're still using SSH to access your GitHub repos, please
| consider using HTTPS access tokens instead. The security is much
| more granular, they're easier to revoke and rotate, easier to
| generate and use safely, they work over HTTP proxies, you can
| specify a different user in the URL
| (https://myuser@github.com/....) allowing for easier use of
| multiple accounts, and of course, you can use them for the GitHub
| API too. Security-wise, most people don't use SSH securely and
| may fall victim to MITM.
| anonymousDan wrote:
| But how do you manage them in practice? At least with ssh
| everything is in one place in my .ssh folder. I suppose I could
| create a .tokens folder or somesuch.
| 0xbadcafebee wrote:
| Git has a lot of options for managing credentials (
| https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage
| https://git-scm.com/docs/gitcredentials
| https://docs.github.com/en/authentication/keeping-your-
| accou... ). For MFA:
| https://github.com/GitCredentialManager/git-credential-
| manag...
|
| The simplest thing is to create a ~/.netrc file:
| machine foobar.atlassian.net login myuser1@mycompany.com
| password isudfiusldifuslkjhdflksjhdf machine
| bitbucket.org login myotheruser password
| kjsdoihohuaoivhdifhuvoiadhf machine github.com
| login companyuser1 password
| ghp_oisjdofhowuefoiusiofus machine github.com
| login personaluser2 password
| ghp_jf9huiehuwfsouyewuhifuh machine circleci.com
| login myotheruser password
| lkjdhiufwhu8ef7yw8yoefhozheofuhouha4lhlWiur
|
| Clone a repository like _git
| clonehttps://companyuser1@github.com/foo/bar.git_ and Git
| will load the right login automatically.
| GRiMe2D wrote:
| Probably ~/.netrc can handle per repository tokens
| keithwinstein wrote:
| I agree this seems to be the currently in vogue practice, but I
| am confused by it!
|
| SSH keys are public-private key pairs, where the private
| portion can live in a hardware token or software agent that
| only signs individual challenges and never exposes the private
| key. (It's possible in theory, although admittedly not common,
| for the user agent to limit approvals to a particular
| repository using the techniques in
| https://github.com/StanfordSNR/guardian-agent . It would be
| nicer if GitHub would enforce granular permissions on SSH
| keys!)
|
| If I understand right, HTTP access tokens are... bearer tokens
| where I have to handle the plaintext (so I can transmit it to
| GitHub) every time I want to use it? I agree it's nice to have
| GitHub enforcing more granular permissions, but even so the
| trade really doesn't seem worth it. I may not be getting
| something here.
| 0xbadcafebee wrote:
| The main reason to use HTTP access tokens is just for the
| more flexible user-facing functionality. Security-wise, the
| issue is (to me) not totally clear-cut.
|
| Yes, with HTTP access tokens, you do have to transmit the
| plaintext each time. (OIDC would be much better, but _The
| Industry Powers That Be_ decided that non-interactive
| networked clients had no need to benefit from federated
| identity and temporary tokens) But the attack vectors
| (broadly) are 1. at-rest storage (credential managers are
| good enough, I think) and 2. HTTPS MITM. If the attacker can
| somehow manage an HTTPS MITM, they get the plaintext token,
| and can then attack that account offline for as long as the
| token is valid. It 's definitely not easy to HTTPS MITM, but
| the protocol is much larger and more complicated than SSH, so
| vulnerabilities are more likely. State actors can do it
| trivially, of course (though this wouldn't be the case if we
| hadn't thrown HTTP Client Certificates out with the
| bathwater!!).
|
| SSH private keys are _technically_ superior, because like you
| say, the private key _can be_ unexposed (if you use a
| hardware token etc). This means that the attack vector left
| is SSH MITM. If the attacker can pull this off, they can only
| attack when you are connecting, because they don 't have your
| private key to perform arbitrary offline attacks. But how
| likely is MITM? Well, when was the last time you verified the
| host keys of GitHub.com? _How_ did you verify it? Are you
| absolutely sure it was correct, and the host keys transmitted
| during your initial SSH connection weren 't a MITM? Even if
| they were correct, can the attacker still MITM you? Well,
| what if they disconnect each of your connection attempts,
| until you try from a different user/computer, or just remove
| or disable your host key cache? They might re-try the attack
| then, and hope you don't verify the host keys this time. All
| this assuming you didn't globally remove the host key checks
| in your SSH config (for example, if you connect to a lot of
| work hosts and you got annoyed by host key verification so
| you disabled it? maybe some automation script in a ci/cd
| process is doing this?)
|
| Ultimately the decision of which to use rests with you.
| Personally, I already rely on HTTPS for most of my security
| on the internet, so I might as well rely on it for my code,
| and gain some extra functionality/convenience. But I do wish
| the HTTPS method used OIDC, and the SSH method had more fine-
| grained controls.
| [deleted]
| xani__ wrote:
| My SSH key is on hardware token. How HTTPS tokens would be more
| secure ?
|
| Other question would be I guess "why we don't just use HTTPS
| client cert auth instead of silly tokens" ?
|
| > Security-wise, most people don't use SSH securely and may
| fall victim to MITM.
|
| The whole things sounds like "okay so some of you are
| incompetent, let's put some measures that annoy the ones that
| are"
| vbezhenar wrote:
| > The whole things sounds like "okay so some of you are
| incompetent, let's put some measures that annoy the ones that
| are"
|
| The proper measure is to secure SSH keys. For me it seems
| crazy that I must Google github host key fingerprints. SSH
| must retrieve those keys over some standard URL like
| https://github.com/.well-known/ssh rather than asking user a
| question that he'll ignore.
| politician wrote:
| About time.
| dyml wrote:
| This is great! It has always been a peeve that they have been so
| coarse grained.
|
| Thank you to the team members that made this happen.
| ocdtrekkie wrote:
| I'm always a little amazed when major tech platforms just now
| manage to get API tokens that are as configurable as MMOs from a
| decade or two ago.
|
| Glad to finally see it.
| princesse wrote:
| Would love to know more about those configurable MMOs you
| mention. Anything in particular I could read/watch?
| Macha wrote:
| Eve Online. Both the official API and a lot of the community
| made stuff for corps (guilds) like TEST, Brave or Goonswarm.
| ocdtrekkie wrote:
| Yeah, that's the main one I had in mind. API key lets you
| select what characters to include, which features are
| visible for that API key, etc. I want to say I wrote code
| that interacted with these back in 2012 or so and this
| wasn't new.
|
| Meanwhile GitHub just got scoped API keys in 2022.
| Cloudflare got scoped API keys maybe last year or two years
| ago? Like to me this has felt like a baseline of API token
| design for a long time.
| simonw wrote:
| It looks like you HAVE to set an expiry on this new shape of
| token?
|
| That's frustrating (though you can at least set it to an
| arbitrary far future date - though apparently limited to a year).
|
| I tend to use this kind of token for automations - where I have
| code running outside of GitHub that needs access to something.
|
| I very rarely want to limit that by time. Having to remember to
| rotate the access token every X months is annoying.
|
| I care much more about audit logs and the ability to easily
| revoke a token.
|
| Is there an argument for why non-expiring tokens are a bad idea
| that I'm missing here?
| saxonww wrote:
| They are not getting rid of the 'classic' access tokens (yet).
| duxup wrote:
| Even before this announcement I had to set an expiration date
| on my GitHub tokens....
| throwup wrote:
| Expiration dates are not required on (now called classic)
| tokens.
|
| https://i.imgur.com/1KQQy4w.png
|
| https://i.imgur.com/MG8slLI.png
|
| The irony is forced expiration will probably hamper adoption
| of the new tokens. Especially for low risk read-only tokens,
| I would rather deal with coarse permissions so I don't have
| to deal with constant alerts to rotate my tokens and having
| to update my app configs and re-deploy etc. I hope they
| reconsider this. By all means make me click through a warning
| or whatever, but at the end of the day I'm an adult, let me
| make my own decision.
| xani__ wrote:
| > Is there an argument for why non-expiring tokens are a bad
| idea that I'm missing here?
|
| it's a band-aid on other people not being able to secure their
| system. Band-aid that solves nothing as if token valid for a
| week or a month leaks you're still fucked.
|
| Now no expiry at all is a problem (you don't want someone
| digging out token from 2 years ago from somewhere to still
| work), but the node actively using service should be able to
| re-generate its own one.
|
| Then you could also get away by super-short tokens (say week)
| that app just re-generates every few days.
|
| For example app can use tokenN to generate tokenN+1 and have
| both of them be valid at the same time for a period (so app
| cluster have time to propagate the new access token before old
| one expires)
|
| And so any leak of old data would be no threat, you wouldn't
| need to have months-long human-regenerated tokens, and it would
| be more leak-proof as just having week old token would be
| inconsequential.
|
| Vs "bother someone every 6 months to click thru the stupid
| panel and put the key in right places just so your
| infrastructure keeps working". MS already does that in other
| places, it's aisine
| samcat116 wrote:
| You'll want to look at Github Apps as thats closer to how
| those works vs how personal access tokens work. Apps have a
| private key that is associated to Github, which is used to
| create and sign JWTs that are valid for some period.
| hartator wrote:
| > Is there an argument for why non-expiring tokens are a bad
| idea that I'm missing here?
|
| I don't think you are missing anything. And your full account
| is anyway hackable if you lose access to your email or phone
| number.
| atlgator wrote:
| Way overdue. They should have launched this when the SolarWinds
| breach happened.
| extantproject wrote:
| https://archive.ph/qIOhw
| remram wrote:
| Apparently they are a different kind of token (github_pat_
| instead of ghp_) in a separate part of the settings. So you can't
| just set the permissions of your existing tokens.
|
| An expiration date is also required for those new tokens with a
| max of 1 year.
| masklinn wrote:
| > An expiration date is also required for those new tokens with
| a max of 1 year.
|
| Gah, so close, yet so far.
|
| But I guess that makes sense for personal tokens and I really
| need to finally look at applications, I assume _they_ have
| fine-grained ACLs in the first place?
|
| Edit:
|
| > The permissions available to fine-grained personal access
| tokens are the same permissions available to GitHub Apps, and
| repository targeting works the same too.
| jtokoph wrote:
| Shouldn't things that expire like access tokens and
| certificates actually last slightly longer than these fixed
| calendar lengths to make renewal or rotation possible on the
| same day/week every year?
|
| For example, if I generate this token on Jan 1, 2023 and it
| lasts 1 year, I'll now need to generate the new one around
| December 21st, 2023 to make sure I have some lead time to deal
| with issues and not wait until the last second. Now, when I
| rotate the second time, I need to do it around December 14th,
| 2024...
| xani__ wrote:
| latchkey wrote:
| That 1 year max is a non-starter for me.
|
| I use PATs for things like a reverse proxy from CloudFlare
| workers to cache hits to a private repo accessed via the GH
| REST API. If I have to remember to rotate my keys every year,
| that's going to suck.
|
| What I want for this usecase is a non-expiring PAT that is
| Organization instead of User based and can be tied to a single
| repo.
| derkades wrote:
| GitHub automatically sends an email a week before expiry.
| latchkey wrote:
| Amazing to think that there are a number of bits of
| critical infrastructure that are dependent on GitHub
| sending an email a week before it goes offline after
| running just fine for a year.
| rad_gruchalski wrote:
| Can't you automate the rotation?
| latchkey wrote:
| No. Turns out there is no way to automate it. PATs require
| sudo mode on GH.
| rad_gruchalski wrote:
| Thanks, turns out it's indeed impossible.
| latchkey wrote:
| Sure, but when does the russian doll end? Who implements
| the automation? How is it tested in CI? Who watches the
| automation to make sure it is working? Who fixes it when it
| is broken once a year. What happens if I get hit by a bus
| or leave the company?
|
| If Github could just solve the issue with a PAT that solves
| my usecase, it seems like a far less brittle solution.
| TechBro8615 wrote:
| It doesn't end, that's why the number of developers is
| increasing indefinitely. The crazy thing is that it seems
| to work, as society has still yet to fall apart.
|
| ...or maybe society _is_ falling apart and it 's the
| fault of programmers. Maybe we're building an unstable
| web of automated abstractions supported by a decreasing
| number of specialists operating at the physical layers
| closer to reality. Maybe one day it will all collapse
| like the collaterized debt obligation market in 2007 and
| we'll be back to making websites with PHP and FTP.
| latchkey wrote:
| > we'll be back to making websites with PHP and FTP
|
| It stopped?
| withinboredom wrote:
| I def missed that memo.
| rad_gruchalski wrote:
| > What happens if I get hit by a bus or leave the
| company?
|
| What happens now if you get hit by a bus and the token
| you issued is leaked, and someone has to rotate it? I
| would assume you have that documented, tested, preferably
| automated?
| xani__ wrote:
| chipsa wrote:
| If you have an automation to update it, why would you
| only run it once a year? why not once a week? then you'd
| know it's broken within a week.
| kevincox wrote:
| What access token does that automation use?
| [deleted]
| samcat116 wrote:
| > What I want for this usecase is a non-expiring PAT that is
| Organization instead of User based and can be tied to a
| single repo.
|
| Authenticating as a Github App will give you that capability.
| latchkey wrote:
| Which is a whole another set of issues and complexity.
| candiddevmike wrote:
| There's a really nice HashiCorp Vault plugin to generate finely
| scoped JIT GitHub token: https://github.com/martinbaillie/vault-
| plugin-secrets-github
|
| I use it with GitHub actions and TF.
| jgillich wrote:
| Waited for this for so long! Thanks GitHub.
|
| But organization tokens would also be nice so you don't have to
| rely on one person to manage it.
| JoshTriplett wrote:
| I'm hoping this leads to being able to set the permissions for
| GitHub Actions tokens as well. For instance, an organization
| should be able to say "the token for this action should also have
| read-only access to check out other organization private
| repositories".
| CGamesPlay wrote:
| Do these new tokens still require the organization and user
| consent? I'm not able to use GitPod as a freelancer because my
| clients don't want to approve the application so GitPod can't
| access the repo. I work around the issue by creating a private
| repo with my SSH private key that has the client's code as a
| submodule and configures GitPod to fetch the submodule using that
| ssh key. It's silly that I have to do that.
| samcat116 wrote:
| GitPod is likely configured as a Github App and not something
| that uses a personal access token. So nothing here changes
| that.
| soulofmischief wrote:
| Long overdue. Tokens have been a huge security hole for a long
| time. Glad to see this finally get some attention.
| alexchantavy wrote:
| Anyone know if there's an API that lets you rotate these new
| tokens? Iirc this didn't exist for the older ones. I looked at
| the linked docs but didn't see anything.
| hirsin wrote:
| This is not supported for fine-grained PATs. Using apps for
| this, which have rotation as a requirement, is preferred.
| babl-yc wrote:
| Are OAuth apps able to take advantage of these fine-grained APIs?
|
| Last time I checked, there was no read-only permission available
| for OAuth apps and you were required to create a one-off Github
| account with limited permissions.
| https://docs.github.com/en/developers/apps/building-oauth-ap...
| wintron wrote:
| You'll want to use a GitHub App[0] for that -- GitHub Apps use
| the same permissions model that these new token types are
| using.
|
| [0] https://docs.github.com/en/developers/apps/building-
| github-a...
| cube2222 wrote:
| _Finally._
|
| The fact that so far any token reasonably operating on
| repositories had to have the full repo scope and, as far as I'm
| aware, the repo scope allows making public repos private (which
| resets all traction you've ever got: stars, forks, etc.), or
| delete them all together, was ridiculous. Now there's a separate
| "Repository Administration" scope.
|
| Moreover, you had to create purpose-suited GitHub accounts if you
| wanted to do cross-repo GitHub Actions (like updating a homebrew
| repo), and grant them access to only that repo, if you didn't
| want to have that GitHub Action have full access on your level.
|
| So yeah, finally. Time to decommission all these existing tokens.
| Thanks GitHub!
| cube2222 wrote:
| Has somebody already found the access level required to make
| IntelliJ accept this new kind of token?
| KenoFischer wrote:
| This is absolutely a step in the right direction. GitHub
| permissions are ridiculously coarse-grained. Hopefully this will
| lead to more fine-grained permissions on GitHub in general.
| psygn89 wrote:
| I migrated from BitBucket recently and was surprised at how
| BitBucket was often ahead of GitHub in CI and API breadth. I
| guess I mistakenly thought GitHub would be miles ahead with its
| popularity and backing.
| another_devy wrote:
| Say what? last time used it, check boxes in markdown still
| didn't work there and CI was cheap knock-off of GitLab which
| doesn't properly work with OAuth
| OJFord wrote:
| I haven't used BitBucket for years, so I'm not commenting on
| that specifically - but to me it makes sense that the
| underdog necessarily forges ahead, because it needs some
| differentiator to persuade people away from the market
| leader.
___________________________________________________________________
(page generated 2022-10-18 23:00 UTC)