zlacker

Reminds me a little of Fly's Tokenizer - https://github.com/superfly/tokenizer

It's a little HTTP proxy that your application can route requests through, and the proxy is what handles adding the API keys or whatnot to the request to the service, rather than your application, something like this for example:

Application -> tokenizer -> Stripe

The secrets for the third party service should in theory then be safe should there be some leak or compromise of the application since it doesn't know the actual secrets itself.

Cool idea!

>>motrm+(OP)
It's exactly the tokenizer, but we shoplifted the idea too; it belongs to the world!

(The credential thing I'm actually proud of is non-exfiltratable machine-bound Macaroons).

Remember that the security promises of this scheme depend on tight control over not only what hosts you'll send requests to, but what parts of the requests themselves.

>>tptace+k2
Did the machine-bound Macaroons ever get written up publicly or is that proprietary?

>>svieir+Al
Like the Tokenizer, I think they're open source.

https://fly.io/blog/operationalizing-macaroons/

>>tptace+k2
How does this work with more complex authentication schemes, like AWS?

>>motrm+(OP)
I've been working on something similar (with claude code).

It's a sandbox that uses envoy as a transparent proxy locally, and then an external authz server that can swap the creds.

The idea is extended further in that the goal is to allow an org to basically create their own authz system for arbitrary upstreams, and then for users to leverage macaroons to attentuate the tokens at runtime.

It isn't finished but I'm trying to make it work with ssh/yubikeys as an identity layer. The authz macaroon can have a "hole" that is filled by the user/device attestation.

The sandbox has some nice features like browser forwarding for Claude oauth and a CDP proxy for working with Chrome/Electron (I'm building an Obsidian plugin).

I'm inspired by a lot of the fly.io stuff in tokenizer and sprites. Exciting times.

https://github.com/dtkav/agent-creds

>>motrm+(OP)
This reminds me of a SaaS that existed 15+ years ago for PCI-DSS compliance. It did exactly that: you had it tokenize and store the sensitive data, and then you proxied your requests via it, and it inserted them into the request. It was a very neat way to get around storing data yourself.

I cannot remember what the platform was called, let me know if you do.

>>orf+pX
AWS has a more powerful abstraction already, where you can condition permissions such that they are only granted when the request comes from a certain VPC or IP address (i.e. VPN exit). Malware thus exfiltrated real credentials, but they'll be worthless.

>>pbowye+V12
There are multiple companies doing that. I was using one a few years ago, also don't remember the name, haha.

I guess it's an obvious thing to sell, if you go through the process of PCI-DSS compliance. We were definitely considering splitting the company to a part that can handle these data and the rest of the business. The first part could then offer the service to other business, too.

>>solati+xn2
I'm not prepared to say which abstraction is more powerful but I do think it's pretty funny to stack a non-exfiltratable credential up against AWS given how the IMDS works. IMDS was the motivation for machine-locked tokens for us.

>>tptace+iD3
There are two separate concerns here: who the credentials are associated with, and where the credentials are used. IMDS's original security flaw was that it only covered "who" the credentials were issued to (the VM) and not where they were used, but aforementioned IAM conditions now ensure that they are indeed used within the same VPC. If a separate proxy is setup to inject credentials, then while this may cover the "where" concern, care must still be taken on the "who" concern, i.e. to ensure that the proxy does not fall to confused deputy attacks arising from multiple sandboxed agents attempting to use the same proxy.

>>solati+NT3
There are lots of concerns, not just two, but the point of machine-bound Macaroons is to address the IMDS problem.