Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Token revocation

biscuitsec.org

Post reply on HN
Print view View original

11–20 of 36 posts

Re: Token revocation

#11

Post by meindnoch »

WirelessGigabit wrote: post #9

You're still stuck with a delay of you fetching the list of revoked tokens and someone getting to your service. And that delay allows someone to come in with a compromised token. However, with short expiration dates you achieve the same. You shorten the duration that a token is valid for. Assume a token is revoked. It can be used against any target until they refresh their revocation list. Same goes with just tokens…

Unless you push the revocation list changes immediately to the service instances.

Re: Token revocation

#12

Post by bob1029 »

This is an ongoing struggle with providers like Azure AD. In our setup, we have function apps that are receiving OIDC tokens from our AAD provider - either from our tenant our others via B2B collab. In this arrangement, it is possible for a user to pass authn for up to 1 hour before revocation in the hosting tenant takes effect. You can reduce this expiration but it can make the experience really bad across the board for all apps.

My current strategy for dealing with this is to add application-specific safeguards that re-verify the assigned roles of whatever user principal is present during more sensitive operations. If we detect that the user principal+token is no longer authorized, we can revoke our session bound to the AAD token and any further access is effectively restricted.

I've seen some other approaches, but I don't think you will get one that fits like a glove without making some alterations to the actual application which is consuming these tokens.

Re: Token revocation

#15

Post by WirelessGigabit »

meindnoch wrote: post #11
WirelessGigabit wrote: post #9

You're still stuck with a delay of you fetching the list of revoked tokens and someone getting to your service. And that delay allows someone to come in with a compromised token. However, with short expiration dates you achieve the same. You shorten the duration that a token is valid for. Assume a token is revoked. It can be used against any target until they refresh their revocation list. Same goes with just tokens…

Unless you push the revocation list changes immediately to the service instances.

Which makes it stateful, but instead of a punch of systems pulling your revocation list you're pushing it.

Re: Token revocation

#16

Post by cratermoon »

WirelessGigabit wrote: post #9

You're still stuck with a delay of you fetching the list of revoked tokens and someone getting to your service. And that delay allows someone to come in with a compromised token. However, with short expiration dates you achieve the same. You shorten the duration that a token is valid for. Assume a token is revoked. It can be used against any target until they refresh their revocation list. Same goes with just tokens…

How about short-lived access tokens and refresh tokens?

Re: Token revocation

#17

Post by dmatech »

It depends on the scenario. I can think of the following, although they're pretty similar.

1. Lost/stolen access token. 2. Lost/stolen refresh token. 3. Disabled account.

In the case of systems like Azure where access tokens have an "audience", they could theoretically send a revocation message to the audience endpoint (which would only need to care about revocations younger than the duration of access tokens, much like a CRL).

Revoking a refresh token would probably need to revoke all access (and perhaps identity) tokens associated with it.

Disabling an account would just need to revoke all tokens associated with it.

Re: Token revocation

#18

Post by ShroudedNight »

I'm not sure I understand the argument that expirations are inadequate: what's the likelihood of ending up with a token compromise without the client machine also being compromised? Further, if the client machine is compromised, isn't token revocation not much more than a fig leaf? If the machine is working correctly, and the user wants to explicitly terminate a session, why is erasing / forgetting the session secret not adequate?

I feel like I'm missing some critical, but non-obvious threat model here.

Re: Token revocation

#19

Post by cratermoon »

WirelessGigabit wrote: post #8
sverhagen wrote: post #2

I'm still skeptical whether expiration times wouldn't be adequate for many applications, assuming these times are short enough, like five minutes?

Same idea with certificates right? No-one checks certificate revocation lists, so Google is shortening maximum lifetimes reducing chance of long-time malicious use.

Right. SSL certification revocation lists have been called "broken in practice". In perfect practice, any time you want to use a cert you have to check the CRL, which means you have to pull the whole CRL or have it on a short enough refresh to satisfy your risk profile. If the attempt to access the CRL fails, then what? Do you trust the cert or not? https://en.wikipedia.org/wiki/Certificate_revocation_list#Pr...

Re: Token revocation

#20

Post by kevincox »

WirelessGigabit wrote: post #9

You're still stuck with a delay of you fetching the list of revoked tokens and someone getting to your service. And that delay allows someone to come in with a compromised token. However, with short expiration dates you achieve the same. You shorten the duration that a token is valid for. Assume a token is revoked. It can be used against any target until they refresh their revocation list. Same goes with just tokens…

You can do something like the True time trick. Services refresh the revocation list every 1s. If they can't refresh for more than 10s they reject authorization. Then on revocation you just need to wait for 15s or so to ensure that the token will no longer be accepted.

This of course means that your downtime tolerance for the token distribution is quite low, but still better than checking revocation on each request.

You can also flip it and track the state of every app server, revocation waits until they have all updated (or been confirmed dead) but now revocation time is unbounded. (And you are tracking more mutable state)

Post reply on HN