0

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 ?

Improve this question
3
  • 2
    I think you should worry about moving to the thin client model as soon as possible and not spend time messing about with the connection string storage at all. Every minute you spend thinking about this is a minute you could be moving to the right architecture.
    – Philip Kendall
    Commented Apr 7, 2022 at 15:36
  • Can you move the database code to a service based approach? The clients would call a service to connect to the database and do CRUD based activities. In that scenario, no database credentials are stored on the client. Not sure how much re-org you have planned.
    – Jon Raynor
    Commented Apr 7, 2022 at 15:58
  • @JonRaynor That's the plan, but when codebase is big, I can't make the jump in one delivery, I will have a transition period with a foot in both
    – Calimero
    Commented Apr 14, 2022 at 8:58

1 Answer 1

Reset to default
2

Since I will have to expose an endpoint to retrieve the key

This seems worse. While you may be sending the key over the network TLS-encrypted, there are ways to intercept that on the receiving machine, and once an attacker has got hold of a valid signature they can replay it.

Doing this properly in a way that actually increases security is quite hard, but any solution will have to cope with the connection string existing in memory on the client somewhere.

I would totally avoid touching this and instead accelerate the migration to a normal web app with normal security properties.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.