0

There is a ton of material available for encryption in general, and I've been reading through it. But this question will not be about the actual encryption...it's how to secure the thing I use to do the encrypting.

I feel like the problem I am trying to solve is a simple one: my application needs to connect to a MySQL database on a website to fetch some information. That requires credentials to log into the database.

The application needs to have those credentials at the ready, so that means storing them securely, such as in app.config. I can encrypt those items and then store them easily enough. I even took a stab at doing that, using aspnet_regiis -pef to encrypt the section of the app.config where those were stored, but that seems to be a non-portable solution (e.g. worked on my dev PC, failed to decrypt on another computer). So if I am wrong about that, then let that be my question: how might that have failed me?

Otherwise, my question is this: how am I supposed to secure the key with which I encrypted the credentials? Is there an established best practice for making the key available to the application, while still protecting it in some way?

DonBoitnott
  • 10,787
  • 6
  • 49
  • 68
  • Why do you need to encrypt on one machine and unencrypt on another? – Millie Smith Aug 24 '17 at 16:47
  • @MillieSmith I don't follow. This application will be used on many different machines. The data was originally encrypted _somewhere_, right? Where it get decrypted will always be _somewhere else_. – DonBoitnott Aug 24 '17 at 16:50
  • Ah, I'm talking about the app.config section. Are you transferring the app.config between machines while it has an encrypted section, or did I read that wrong? – Millie Smith Aug 24 '17 at 16:51
  • @MillieSmith Yes, the app.config will ship with the application. It's a WPF desktop app. That way each new installation already has it there for use. – DonBoitnott Aug 24 '17 at 16:51
  • I think you're going to have to encrypt it on each machine or find another way to get sensitive information to them. The provider mentioned in your second link for encryption is DataProtectionConfigurationProvider, and that uses DPAPI, which isn't portable across machines. – Millie Smith Aug 24 '17 at 16:58
  • @MillieSmith What does "encrypt it on each machine" mean, exactly? These are fixed credentials for an account in MySQL. They are not user-facing, nor should they be user known, so how would I go about encrypting them at each machine? – DonBoitnott Aug 24 '17 at 17:00
  • The ProtectedData Class is an easy way to provide some basic protection for a set of data, it wont stop a determined user, but then nothing will - not least because its always possible for them to sniff the data going out from their machine over the wire. Lots of discussion on this if you google for *stackexchange secure api endpoint* – Alex K. Aug 24 '17 at 17:30
  • @AlexK. Thanks, Alex. I'll try that for some more reading material. As for the class, I think that is DPAPI as well, and as Millie pointed out, it's not portable to other machines, which I have to have. – DonBoitnott Aug 24 '17 at 17:35

2 Answers2

1

"You cant hide secrets"

Realistically you cannot secure anything you distribute. Your connection string is distributed in your app.config to potentially millions of customers, or at least can be copied millions of times. Your encryption algorithm may be very complex, but you must at least contain the decryption code in your .net application; which can be readily decompiled. All the hacker has to do is work out how/where your store your key. If they user doesn't supply it as part of the login process then you can't really secure the connection.

In the web application world we keep the connection string in web.config encrypted using the application pool service account credentials; only the app pool service account can read it. The user of the web site never gets access to the web.config, and if they did, the firewall between the DMZ and the database server would prevent them from attempting a connection. You lack any of these safeguards in a client-server application.

Ideally you would provide your end user with a SQL Server login based on their windows account credentials, or a username/password; you secure their SQL account rather than the ability to attempt to connect. This is reasonably secure in an intranet scenario, as SQL Server can delegate authentication lockout etc to the Windows Server allowing you to do three-strikes based login policies; but you cannot secure the attempt to connect - only the success of the connection attempt.

PhillipH
  • 6,182
  • 1
  • 15
  • 25
  • I've read enough to know that at least most of what you're saying is true. I wish this was a case of letting users have their own login, but it's not that kind of login or that kind of data. I guess I am in that "find another avenue" spot, after all. – DonBoitnott Aug 24 '17 at 17:37
0

To be honest, you're not going to have a failsafe way of doing what you want - anyone you're distributing the app to can decompile and examine what you've sent them. Literally any security scheme you can think up, the attacker can simply read the code for.

Instead, I think you should put some minor security on that end (block the casual/curious people with some straight-forward hard-coded-key encryption, knowing that you're not going to stop a determined attacker) - and instead focus on locking down the SQL end as much as possible. Those account credentials you're giving out through your app? Give it the bare minimum of Stored Procedures it needs to do its job, and then lock it out of all the other tables/views/etc. Connect in to the SQL database as your app's account user, and try to see if you can perform anything malicious - screwing with table data, dropping objects, etc - and then take steps to mitigate/remove those vulnerabilities.

If that's not sufficient, your next best bet is to program a middle layer. Make a web service, and have it be the one to connect in to SQL. The WPF App doesn't hook into SQL at all, and has to go through the web service to get/change/etc the data. But it's important to realize that an attacker can still screw around with your data - they can directly call your web service instead of going through the WPF app. The only thing you gain is that the attacker doesn't have a SQL login.

Kevin
  • 2,133
  • 1
  • 9
  • 21
  • Good advice. I've already taken the step of preparing a minimalized account just for this purpose, to mitigate damage done if all else fails. – DonBoitnott Aug 24 '17 at 18:19