There are more kinds of tokens than dreamt of in userland's philosophy
There are more kinds of tokens than dreamt of in userland's philosophy
Posted Jun 9, 2026 20:17 UTC (Tue) by quotemstr (subscriber, #45331)Parent article: Eliminating long-lived credentials with trusted publishing
This dire conclusion applies only to *bearer* tokens. The word "bearer" means that, like cash, anyone bearing one can use it. Not all tokens are bearer tokens!
We have the technology to mint hardware-bound tokens for which exfiltration is impossible or useless. We can, for example, create public-private keypairs in which the private key lives in a machine's TPM (or equivalent) *and never leaves it*. You create a hardware-bound token by telling the TPM itself to generate a private key, a public key, and a CSR. You send the CSR to some other party, which checks that the CSR cryptographically attests "my private key live in hardware", and, if true, signs your CSR and gives you a certificate. You then use your certificate to attest your idenity remotely via mTLS, use the keypair to sign PyPI releases, or whatever else you want. The token is forever bound to your specific hardware. Short of breaking your secure execution environment, nobody is going to exfiltrate it or bypass your rate limits or usage restraints.
Hell, a sufficiently powerful TEE could enforce the invariant that it signs only releases themselves attested end-to-end, SLSA-4 style.
While I'm glad we're paying attention to token exfiltration in this era of credential-stealing worms and LLM-accelerated exploits, we should be thinking about more than tweaking TTLs. Hardware-bound tokens resist attacks that no pure-software scheme can ever fully mitigate.
