C
C#15mo ago
شيطان

❔ Storing connection strings securely in my c# .net app

Hello, I'm wondering about the most secure way to store connection strings in my application. Currently, I'm considering using Azure Key Vault for storage. As far as I understand, the SDK uses TLS for end-to-end encryption, and by not hard-coding the connection strings into the app, I am enhancing security. My plan is to grant access to an Azure App Registration Principal via Vault Policies and then authenticate the Azure App to my C# app using Certificate Authentication. I have implemented some code that successfully retrieves the secrets from the key vault, but I'm not entirely confident in my knowledge of this topic. Specifically, I am uncertain whether passing the retrieved key directly into my SQL query in C# is now considered "secure", I assume so as the end to end communication is encrypted while being delivered, and I'm not storing this value in memory. I'm passing it straight into my sql query using the "using" statement. Previously, I stored the keys in memory, which could be vulnerable to memory attacks, but I am assuming now me doing it this way it is secure? The SQL Strings are using the "Using" statement, so they should be disposed off when finished. I think perhaps I have maybe achieved this? The reason for cert auth is, the exe is run from a network share by multiple users and I need seamless authentication without bothering the users. Furthermore, there is still a "clientid" and "tenantid" and cert "thumbprint" I need to store in the code, but what I have done is stored these on the project properties user level as a string, but these are encrypted. The app when launched for the first time will create a self signed certificate and use this to encrypt these values which is done per user, so each user uses their own self signed cert, and decrypt this, stored at user level, so at least nobody can just open the file and read it in plain text.
6 Replies
mtreit
mtreit15mo ago
As long as you are ok with users of your app being able to get the secret in question...
شيطان
شيطان15mo ago
You're right, I spent so long on developing and researching this today that I forgot the whole point I'm doing this. I never used Windows Authentication with SQL as I don't want them to have SQL access, hence I'm using SQL User accounts. What would you recommend? I'm struggling to find something that matches what I need, being an exe that is run from a network share by multiple different users on their machines, but I need a way to store these connectionstrings securely.
mtreit
mtreit15mo ago
If your app is talking directly to SQL and that app is running on some user's machine, that user has access to the SQL server period. There are any number of ways they could see the connection string, either with a debugger, a memory dump, decrypting the TLS traffic, etc. The only way to actually secure access to the database is to have the application talk to a server you control, and have that server access the database.
شيطان
شيطان15mo ago
Firstly, thanks for your time on this. I've done a brief search and from what I understand, in order to achieve this I need something like: -Client(Running App) -Server(Webapi for the requests) -SQL(Backend) Does it make sense for me to use Azure Key Vault with the Server to store the secrets as I explained above for security? I am then assuming my c# app will make requests to the server via a class like apiclient. With regards to the client to server communication, I am assuming can be done via Windows Authentication to avoid the password storing headache. Just need to be pointed in the right direction and I can do the rest of the research myself, thanks again.
mtreit
mtreit15mo ago
Client / server authentication is kind of a big topic - there are a lot of options there for handling authentication. The industry standard tends to be OAuth OpenID Connect, but if you can get away with Windows auth that is probably much simpler. And yes, KeyVault is a great choice for actually storing secrets.
Accord
Accord15mo ago
Was this issue resolved? If so, run /close - otherwise I will mark this as stale and this post will be archived until there is new activity.