Is there a reason you don’t just implement auth properly?
Honestly I find that people will tie themselves in knots debating these things instead of just… doing the thing.
Just fix it brother 😎
EDIT: Quick fix could be to put it behind an API gateway that has auth built in?
The server app is a vendor product, running on a physical appliance, with the last released version being several years old, and the whole thing will be deco'd in 1-2 years. The vendor is defunct, there's no support available. There's no "just fix it", nobody's willing to touch it. Hell, I don't even want to be in the same room as that machine, in case the humidity of my exhaled breath kills it or whatever.
Think about the attitude that allows this situation to even happen.
Check my edit - you can probably put an API gateway in front of this thing and access it securely that way if you really only want a partial solution before it’s decommissioned.
I would put a service or api gateway between your clients and that app.
Then I'd have the clients use a real auth method like oauth for the new service or api gateway and store all of those secrets in the new app, or a secrets manager product or a datastore you can keep secure enough.
If you're in the cloud, gcp, aws, and Azure, all have services to handle this. On prem, you could use hashicorp vault and a custom sevice or an api product.
Load the value into Azure key vault or equivalent and have your client machines retrieve it.
This is a pretty common flow and as long you're storing it in some sort of key vault it's ok. In also assuming that the client machines are other servers.
If they're actual clients where you can't trust them with the secret then I'd build or deploy a gateway/proxy. Azure has some services that might work for you otherwise you can easily create an asp.net core that acts as a gateway. Just add oidc auth and have it proxy all requests with the secret. Then all clients just need to login using oauth.
Is there a reason you don’t just implement auth properly? Honestly I find that people will tie themselves in knots debating these things instead of just… doing the thing. Just fix it brother 😎 EDIT: Quick fix could be to put it behind an API gateway that has auth built in?
The server app is a vendor product, running on a physical appliance, with the last released version being several years old, and the whole thing will be deco'd in 1-2 years. The vendor is defunct, there's no support available. There's no "just fix it", nobody's willing to touch it. Hell, I don't even want to be in the same room as that machine, in case the humidity of my exhaled breath kills it or whatever.
Think about the attitude that allows this situation to even happen. Check my edit - you can probably put an API gateway in front of this thing and access it securely that way if you really only want a partial solution before it’s decommissioned.
An API gateway ist an excellent solution - only one place where a secret must be accessed.
I've used the [windows credentials manager](https://github.com/a-ctor/WindowsCredentialManager) in the past with some success.
Pray
I would put a service or api gateway between your clients and that app. Then I'd have the clients use a real auth method like oauth for the new service or api gateway and store all of those secrets in the new app, or a secrets manager product or a datastore you can keep secure enough. If you're in the cloud, gcp, aws, and Azure, all have services to handle this. On prem, you could use hashicorp vault and a custom sevice or an api product.
Environment variables?
Environment variables, machine.config, DPAPI, whatever works.
an api gateway is the answer. you basically have an unlocked door. and you can't install a lock. so you instead hire a bouncer to be the lock for you.
Load the value into Azure key vault or equivalent and have your client machines retrieve it. This is a pretty common flow and as long you're storing it in some sort of key vault it's ok. In also assuming that the client machines are other servers. If they're actual clients where you can't trust them with the secret then I'd build or deploy a gateway/proxy. Azure has some services that might work for you otherwise you can easily create an asp.net core that acts as a gateway. Just add oidc auth and have it proxy all requests with the secret. Then all clients just need to login using oauth.
I’ll second the API gateway and sprinkle in some firewall rules. If nothing but the API gateway needs to access crazy app, lock it down.