1

We have to protect a database connection string for a .NET desktop application that has an application-level database user. One option is to encrypt a section of the app.config using asp_regiis. But then every user of the application needs to have the key installed on their PC.

If an intranet IIS server has SSL and Microsoft Windows Authentication was in place, would an ASP.NET web-app that accepted an encrypted value and returned a plain text be a viable alternative to installing the keys on every user's machine?

With the web app, no user would be able to export the key from their local container, and so the web app approach seems the more secure of the two.

10
  • What would stop anyone replicating the call to the server to get the plain-text password? – TripeHound Jul 15 '20 at 15:14
  • "I don't know if it would stop a hacker, but the application could send a value encrypted with the server's public key, which key our users wouldn't know; and the server would not divulge anything if someone merely opened the URL with one argument. Our users wouldn't even know that the web app existed. The value could change based on some condition, e.g. if it's Tuesday, send X. – Tim Jul 15 '20 at 16:57
  • Steve's answer is a much better option. When you need to connect directly to a database from a desktop app, Integrated Auth is the best option because it gives you a way to both uniquely identify users, and a built in way to manage permissions at the database level for a user or group of users. – Xander Jul 15 '20 at 20:00
  • You mean that you need to keep the connection string that the application uses secret? That's impossible. Change your goal. – Jasen Jul 16 '20 at 8:29
  • @Xander: We have undergone security audits where the auditing company explicitly advised against using Integrated Security. – Tim Jul 16 '20 at 9:34
1

Well, which is it? A user or an attacker? A user doesn't care about the key, an attacker does.

An attacker doesn't really even care about the key, but rather the password. Moreover, an attacker doesn't really even care about the password, but in fact the data in the database.

If an attacker could reasonably get the key out of the user profile (which is what you're suggesting is the attack) they could easily just observe the connection to the service or even the database itself.

The correct solution is to move the connection to the database out of the context of the user. Since that's probably not feasible, you should consider switching to a non-credential-based mechanism like Windows Integrated Auth. You seem happy to do it for the service, so why not the database?

Note however that this doesn't actually solve the problem, it just limits the ways an attacker can connect to the database.

3
  • When we encrypt app.config with aspnet_regiis, the user must have the key installed in a custom key container on their PC; anyone who knows where the app.config files are copied on the local PCs could run aspnet_regiis -pdf against the file to access its secrets. With our config there's an encrypted symmetric key as well which would be exposed. For us, switching to Integrated Authentication solves only one part of the problem. It seems Microsoft's Azure Key Vault is something like the web app that I have in mind, except that Azure applications have a built-in service identity. – Tim Jul 19 '20 at 20:13
  • The service identity is the missing key to the puzzle for desktop applications. – Tim Jul 19 '20 at 20:14
  • More importantly, the threat model is the missing thing here. You don't describe it. – Steve Jul 20 '20 at 14:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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