[simonw]

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?

[xani__]

> 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

[greggman3]

> but the node actively using service should be able to re-generate its own one.

Which in order to do it would presumably need some meta-token you use to authenticate to get a token. how is that more secure? It sounds like I just need the meta-token instead of the token. So, same amount of security as just a non-expiring token

[samcat116]

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]

> 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.

[saxonww]

They are not getting rid of the 'classic' access tokens (at least not yet). I think this new feature is geared more towards organizations where credential rotation has to happen for audit/policy/regulatory reasons anyway; it's probably nice to have GitHub ensuring that you can't have a policy violation while also nagging a credential owner if a credential is about to expire.

[insanitybit]

> Is there an argument for why non-expiring tokens are a bad idea that I'm missing here?

Because people leave tokens around that are no longer used and forget about them, of course.

[withinboredom]

Ok. But 1 year means I have less than a year, then less than a year again, then less than a year again. Can’t even do one month and just do the first of every month. These expiration times make no sense, or they make sense for machines but not humans.

[insanitybit]

You don't have to revoke a key as soon as it is rotated. If you rotate every week you can have a job that runs every week, offset by one day, to revoke.

[withinboredom]

Right, but there’s no way to do that on the same day every year, or even the “first Tuesday of every June” because that may or may not always fall within a year.

Also, these tokens have to be rotated by a human. So weekly is way too often.

[insanitybit]

> Right, but there’s no way to do that on the same day every year, or even the “first Tuesday of every June” because that may or may not always fall within a year.

Why would that matter?

[withinboredom]

Because we are humans. If I say “see you in a year” that doesn’t mean a year to the second.

[robertlagrant]

> If you rotate every week you can have a job that runs every week, offset by one day, to revoke.

This might be a silly question, but how do you authenticate that revoke?

[insanitybit]

Usually tokens have the right to revoke themselves or you have a separate system like Vault that manages revocation.

[simonw]

I think what I want here is a token which expires if it hasn't been used for six months.

[duxup]

Even before this announcement I had to set an expiration date on my GitHub tokens….

[throwup]

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.

[duxup]

I have some like that too.

It’s just that last time I tried to create some with no exp they wouldn’t let me.

[jiggawatts]

To the people responding to this saying that "expiry is mandatory", you're missing a key aspect: expiry is mandatory for uncontrolled secrets.

Passwords and API Keys are uncontrolled. Once they've leaked, they're "out there", and you can't know where they've been copied, stored, and who has them. There is no central, authoritative list of "currently held credentials". They're literally "bearer tokens", like cash-in-hand versus something held in an account that's recorded on a ledger.

This makes password-like credentials inherently risky, so people work around these issues by:

- Restricting network access

- Restricting the time for which they are valid

- Restricting who can get any access at all.

These restrictions then "get in the way", even for legitimate use. Network access restriction mean that everyone has to be on the VPN. I mean the VPN, because you can't be on two VPNs (in general). This limits business activities such as querying across federated systems. All "access control" now involves the network team. The guys "running cables" have to be involved in database access!

Time restrictions mean that as things expire, they break. One year expiry is just long enough that people have moved on from their six-month contracts, and the new guy has no idea why everything went down at 4:55pm on a Friday. Sure, you can automate the rotation away, but then the automation system itself inherits the same security boundary as the tokens it is managing. You can't automate your way out of this, because then it becomes turtles all the way down.[1]

Restricting who can get any access at all because of the legitimate fear that they will leak their API keys hampers productivity. If developers can't be trusted not to copy-paste keys into their code[2], then they won't be given keys at all. This limits what they can do. Similarly, even read-only access will be restricted, so you end up with systems where data is copied over-and-over into other systems because direct access "wasn't an option".

Generally my advice to architects and developers is to avoid passwords or API Keys like the plague. Use something like Azure Active Directory with managed user identities, which allow "secretless" access. This access is also self-documenting, with a central authority tracking who has access. You can't "copy" a managed identity or "run off with it". There is no way to paste one of these into Git, or leave it on a laptop that is being disposed of.

[1] One particularly problematic security risk with things like GitHub PATs is due to GitHub Actions. Previously, Git was "just code", posing only a slightly greater risk than documentation. Now, it's managing deployments of apps, and their secrets, making it super dangerous to give anyone access to the repo! There have been several major breaches because of this.

[2] In the last year or so working with over a dozen developers moving into cloud apps, I observed literally every single one of them pasting API Keys or similar secrets directly into the code and then checking that in to Git.

[dustedcodes]

I think that is a reasonable limit.

It prevents you from having forever tokens floating around, somewhere left and forgotten many years ago and perhaps getting leaked one day through some vulnerability in that particular system.

Just automate the recycling of your tokens if you can't be bothered to review it once a year and generate a new one yourself. If security to your own repos is not worth of a one time 20 minute effort to automate this then I wonder what is.

[simonw]

How do I automate recycling tokens?

I've not found an API endpoint for setting a GitHub Actions secret, for example. Or for generating fresh time limited personal access tokens.