from Hacker News

Tokenized Tokens

by darthShadow on 7/12/23, 6:21 PM with 30 comments

• by agwa on 7/12/23, 11:01 PM

  Props to Fly for open sourcing this!

  Another thing you can do with a proxy like this is limit the types of requests which can be made to the 3rd party service. This is very useful if the 3rd party service doesn't support fine-grained permissions for its API keys and you don't want your application to have full access to the 3rd party service.

  (I implemented something very similar for my company, which I described here in case anyone is curious: https://sslmate.com/resources/protecting_customer_credential...)

• by ShaneCurran on 7/12/23, 9:10 PM

  Shameless plug, but we have a product at Evervault[0] called Outbound Relay[1] that’s basically a hosted, managed version of this flow. Secrets can be encrypted anywhere you collect them (either from third-party APIs or directly from the user in their browser) and then used any time you send a request to a downstream API provider.

  [0]: https://evervault.com

  [1]: https://docs.evervault.com/products/outbound-relay

• by evisdrenova on 7/12/23, 8:12 PM

  This is pretty cool and I think the right direction. Would like to see more companies do this. I've built out systems like this in the past that essentially only handle tokens instead of sensitive data whether it's secrets, PII, etc.

  You can also take this a step further and do mathematical operations on encrypted data using homomorphic encryption without ever having to decrypt the data.

  Just one small nitpick (mainly because I worked in this space for a few years) is that tokens and encrypted values are different. Tokens aren't encrypted and instead randomly generated using a KV pair look up table so that an attacker could never reverse engineer them. Whereas encrypted values obviously use a key (whether symmetric or asymmetric) and could theoretically (although pretty much never practically if you're using something like AES256) be hacked if someone got the key.

• by tptacek on 7/12/23, 6:33 PM

  Psyched to get this out (I mean, I didn't do any of the work, but I'm still psyched it's getting out). I'm also a little bit surprised Vault doesn't already have a feature like this as a Secrets Engine.

• by js2 on 7/12/23, 10:52 PM

  Summary: fly.io wrote two new programs ("some little security thingies") to reduce the attack surface of their codebase.

  1. "Tokenizer is an HTTP proxy that injects third party authentication credentials into requests. Clients encrypt third party secrets using the proxy's public key. When the client wants to send a request to the third party service, it does so via the proxy, sending along the encrypted secret in the Proxy-Tokenizer header. The proxy decrypts the secret and injects it into the client's request. To ensure that encrypted secrets can only be used by authorized clients, the encrypted data also includes instructions on authenticating the client."

  https://github.com/superfly/tokenizer

  2. "Ssokenizer provides a layer of abstraction for applications wanting to authenticate users and access 3rd party APIs via OAuth, but not wanting to directly handle users' API tokens. Ssokenizer is responsible for performing the OAuth dance, obtaining the user's OAuth access token. The token is then encrypted for use with the tokenizer HTTP proxy. By delegating OAuth authentication to ssokenizer and access token usage to tokenizer, applications limit the risk of tokens being lost, stolen, or misused."

  https://github.com/superfly/ssokenizer/

  If these sound interesting to you, click the submitted link for the "big long essay about how the thingies came to be."

• by ec109685 on 7/13/23, 12:58 AM

  I wish more things / ecosystems supported mTLS. Then you aren’t storing any long lived tokens. You exchange per instance metadata with key material to generate client tls certs that are then used to auth server calls. The certs have a short lifetime.

• by ozfive on 7/12/23, 11:16 PM

  Private Key is held in an environment variable called 'OPEN_KEY'. Wouldn't they be better served retrieving the key from Vault or KMS for revocation purposes?

• by salgorithm on 7/12/23, 9:38 PM

  I could imagine developers using something like this to get credentials off laptops.

• by e12e on 7/13/23, 7:03 AM

  This looks great. A little unfortunate that this effectively requires plaintext http/1.1 (and won't work with "standard" encrypted http/2) - but that's not fly.io's fault.

• by twodave on 7/13/23, 12:18 AM

  First read this as “Tokenized Tolkiens”. What a let-down.

• by lll-o-lll on 7/13/23, 2:19 AM

  It’s cool, but the http connection to the proxy makes this only viable with the “vpn” tunnel they use. Otherwise MITM becomes a thing.

  Also, you’ve gotten the secret off the client machine, but the attacker can still do anything the secret can do by using the proxy? Perhaps I’m missing something.