41–50 of 148 posts
Earlier quoted context omitted.
It isn't until it is. And wherever you store it is a juicy target.
When will "until it is" kick in? It has never kicked in for me...
Earlier quoted context omitted.
The problem is that you don't have control over what third parties are doing here. You may have control over the policies associated with tokens issued by your identity provider, but how do you audit the policies that third party services are applying to their tokens?
So I have a service using openid and I use google to authenticate the person logging in. I do that, then that's done. Now I could simply issue a session cookie, or a permament cookie, to the client so we never have to use google again. Or I could make it so that cookie lasts 10 minutes before reauthentication. I can use a refresh token which means they don't need to reauthenticate but if google expires the connection…
Earlier quoted context omitted.
I don't understand the argument here, if you're not issuing the tokens then they're not your responsibility. Can you give a more fleshed out example, why should you audit third party services?
Hypothetical: I have a Github Enterprise org. Users log in via my identity provider to gain access. Github then issues a long-lived oauth token to the Github Desktop app. An attacker compromises a user's laptop and copies that oauth token. That attacker now has access to all my private repos until I notice and revoke it.
That's a legitimate concern, any compromise of the SSI needs a complete refresh of anything it's touched, including refreshing all API keys, keyrings, etc.
Hopefully as the ecosystem matures it'll be easier to en-masse mark an account as compromised and have that status propagate and trigger resets of affected credentials.
A similar threat is insider threat, (probably actually a greater threat) where someone leaving a company could generate tokens which grant them access for long after they've gone.
If reason about how that's typically managed (disabling their upstream accounts) that gives insight into how to deal with your initial concern, it should be managed in the same way.
Earlier quoted context omitted.
Hypothetical: I have a Github Enterprise org. Users log in via my identity provider to gain access. Github then issues a long-lived oauth token to the Github Desktop app. An attacker compromises a user's laptop and copies that oauth token. That attacker now has access to all my private repos until I notice and revoke it.
That's github's service, before choosing to use it you should look at these policies (who and how github enterprise trust tokens) and see if it matches your needs. If you were running the service, then the power to trust those tokens is with you.
So don't set the token to expire after the "heat death of the universe", make the user reauthenticate after an appropriate time for the service being used.
In our case, we use JWT tokens that contain a few claims, are signed, have an expiration token, etc. Not awful at all. Verifiable information, signed by us with our private key, exchanged over https. That's not information the bearer of the token needs to be aware of but it is something our APIs can trivially verify and use as a basis for authenticating the bearer of the token. Pretty neat mechanism. Nothing wrong with it. Used at scale by world + dog on the internet without a lot of issues.
And before somebody starts ranting about JWTs being awful: same argument. They don't have to be but they can might if you decline to use sane crypto. So, use it properly and you're fine. It's not that hard.
> In theory you could just hand someone a randomly generated blob, but then you'd need to keep track of which blobs you've issued and when they should be expired and who they correspond to Is this so difficult?
If the client starts using the token immediately, propagating that token to all servers before the first use is a harsh requirement.
So what is the option, actually? TEEs and TPMs which the end-user and device owner/operator/admim have zero control or insight into (or is this also under the scope of the "local enclave"?) OP doesn't propose any in their opinion better alternatives. I'd argue for (roughly, on the move) client-side keys and cryptographic signing (mutual certs basically) and issuing session certs which could be counter-signed, with a…
Earlier quoted context omitted.
Hypothetical: I have a Github Enterprise org. Users log in via my identity provider to gain access. Github then issues a long-lived oauth token to the Github Desktop app. An attacker compromises a user's laptop and copies that oauth token. That attacker now has access to all my private repos until I notice and revoke it.
So you're worried that a very short lived compromise of a SSI / federated auth layer can lead to long-lived compromises of everything it grants access to because a short time can be used to generate long-lived auth to third parties? That's a legitimate concern, any compromise of the SSI needs a complete refresh of anything it's touched, including refreshing all API keys, keyrings, etc. Hopefully as the ecosystem matu…
Earlier quoted context omitted.
Isn't the fundamental difference that a password needs checking against a stored per-user value such as password hash and therefore needs a database lookup, while a token can be validated through just the cryptographic signature and therefore avoids hitting the central database?
Yes but then you add revocation and you are back at a centrally stored database to check against.
There are scenarios where it still makes sense.
It's plausible that it would more efficient for some high traffic services to push (the somewhat rare) revocation notices out to endpoints as still being more efficient.
For example imagine a whatsapp clone. People send thousands (probably tens of thousands) more messages than they issue password/auth resets.
Having the incoming message endpoint maintain a cache of recently expired tokens would let you set a reasonably long (e.g. 24 hr) token expiry. You could have the app re-auth in the background on start-up and/or when it detects the expiration window is closing, while incoming messages avoid hitting the central DB for auth.
Maintaining a cache of expired tokens pushed to endpoints would be vast orders of magnitude smaller than maintaining a cache of all session keys.
I don't know for sure though, perhaps central session caches are just more practical and secure anyway for these kind of end-user endpoints.
In some ways this is similar to the Certificate Revocation List handles certs. There are certificate revocation notices that are used instead of needing to check centrally the validity of all certificates.
That said, the CRL has essentially been deprecated in preference of a lookup model.
Is there a difference between that token and a password? Yes, the token is bigger and created by somebody else, yet for all practical means it walks like a password and quacks like a password...
Isn't the fundamental difference that a password needs checking against a stored per-user value such as password hash and therefore needs a database lookup, while a token can be validated through just the cryptographic signature and therefore avoids hitting the central database?