I started to work on a 16 years old .net framework app that didnt receive any love for a decade and I have some time to "put it up to standards".
One of the things that ruffle my feathers is the direct connection between a desktop application on end-user workstation and the database. In the future, I will move business logic little by little to a new web api until the desktop client is reduced to a glorified view and severing connection with DB is possible. In the meantime, I have to live with a connection string in a file on the end-user workstation.
The original dev team fortunately didnt write in clear the connection strings. They used Microsoft's sn.exe to generate a strong name key for the assembly, then generated an obfuscated decryption dll that first checks the caller is indeed the intended assembly, then decrypt the encrypted connection string with a key somewhere in that obfuscated gibberish. They also provided an encrypting executable to generate the matching encrypted config file content.
So currently the binaries of the application hold both the decryption key and the decryption algorithm in the same .dll, on end-user workstation, only protected by a layer of code obfuscation that I have to blindly trust.
I would like to move the secret to a distant password vault and not store the key in the client machine. I also don't want to redeploy a new version of the desktop app on all clients if I want to change the secret for whatever reason. Since we don't have a password vault in this company, I will have to do it all myself.
My idea was to store the decryption key as an environment variable on the API server (I would prefer another server but I'm also short on VMs), and retrieve it when client needs it. Since I will have to expose an endpoint to retrieve the key, I was thinking about reusing the idea of the strong name key that signs the assembly, rejecting any call that don't provide the signature, and protecting myself from malicious assembly swaps. What do you think ?