TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Tokenized Tokens

190 点作者 darthShadow将近 2 年前

11 条评论

agwa将近 2 年前
Props to Fly for open sourcing this!<p>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&#x27;t support fine-grained permissions for its API keys and you don&#x27;t want your application to have full access to the 3rd party service.<p>(I implemented something very similar for my company, which I described here in case anyone is curious: <a href="https:&#x2F;&#x2F;sslmate.com&#x2F;resources&#x2F;protecting_customer_credentials" rel="nofollow noreferrer">https:&#x2F;&#x2F;sslmate.com&#x2F;resources&#x2F;protecting_customer_credential...</a>)
评论 #36710522 未加载
ShaneCurran将近 2 年前
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.<p>[0]: <a href="https:&#x2F;&#x2F;evervault.com" rel="nofollow noreferrer">https:&#x2F;&#x2F;evervault.com</a><p>[1]: <a href="https:&#x2F;&#x2F;docs.evervault.com&#x2F;products&#x2F;outbound-relay" rel="nofollow noreferrer">https:&#x2F;&#x2F;docs.evervault.com&#x2F;products&#x2F;outbound-relay</a>
evisdrenova将近 2 年前
This is pretty cool and I think the right direction. Would like to see more companies do this. I&#x27;ve built out systems like this in the past that essentially only handle tokens instead of sensitive data whether it&#x27;s secrets, PII, etc.<p>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.<p>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&#x27;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&#x27;re using something like AES256) be hacked if someone got the key.
tptacek将近 2 年前
Psyched to get this out (I mean, I didn&#x27;t do any of the work, but I&#x27;m still psyched it&#x27;s getting out). I&#x27;m also a little bit surprised Vault doesn&#x27;t already have a feature like this as a Secrets Engine.
评论 #36706327 未加载
评论 #36702944 未加载
评论 #36700778 未加载
js2将近 2 年前
Summary: fly.io wrote two new programs (&quot;some little security thingies&quot;) to reduce the attack surface of their codebase.<p>1. &quot;Tokenizer is an HTTP proxy that injects third party authentication credentials into requests. Clients encrypt third party secrets using the proxy&#x27;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&#x27;s request. To ensure that encrypted secrets can only be used by authorized clients, the encrypted data also includes instructions on authenticating the client.&quot;<p><a href="https:&#x2F;&#x2F;github.com&#x2F;superfly&#x2F;tokenizer">https:&#x2F;&#x2F;github.com&#x2F;superfly&#x2F;tokenizer</a><p>2. &quot;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&#x27; API tokens. Ssokenizer is responsible for performing the OAuth dance, obtaining the user&#x27;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.&quot;<p><a href="https:&#x2F;&#x2F;github.com&#x2F;superfly&#x2F;ssokenizer&#x2F;">https:&#x2F;&#x2F;github.com&#x2F;superfly&#x2F;ssokenizer&#x2F;</a><p>If these sound interesting to you, click the submitted link for the &quot;big long essay about how the thingies came to be.&quot;
评论 #36703736 未加载
ec109685将近 2 年前
I wish more things &#x2F; 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.
评论 #36705105 未加载
ozfive将近 2 年前
Private Key is held in an environment variable called &#x27;OPEN_KEY&#x27;. Wouldn&#x27;t they be better served retrieving the key from Vault or KMS for revocation purposes?
评论 #36703006 未加载
salgorithm将近 2 年前
I could imagine developers using something like this to get credentials off laptops.
e12e将近 2 年前
This looks great. A little unfortunate that this effectively requires plaintext http&#x2F;1.1 (and won&#x27;t work with &quot;standard&quot; encrypted http&#x2F;2) - but that&#x27;s not fly.io&#x27;s fault.
twodave将近 2 年前
First read this as “Tokenized Tolkiens”. What a let-down.
评论 #36703596 未加载
lll-o-lll将近 2 年前
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.<p>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.
评论 #36704335 未加载