nr: #2 dodano: 2016-12-29 14:12
I'm answering this to address security for a local application, as that's what OP's situation sounds like, despite other answers treating it as if it's a web application.
If a single database is shared by multiple users with different security concerns, as I suspect it is, then you really shouldn't store the database connection string locally, in the code, in the config, encrypted in the config, etc. The client should never have this information. This is the only way to truly guarantee security client-side.
A determined person can simply reverse-engineer your code, and unencrypt the connection details. Furthermore, if they use something like .NET Reflector do debug your code, they can use reflection to pull the connection string, including password, out of the connection object. Then it's trivial for them to connect directly to your database and extract any information they want. Of course you could have an IP whitelist, but if one of those users is bad then you still have the same issue.
My recommendation is that you create a web service which will manipulate your database. The software that your end-users use then simply authenticates itself with the web service using the user's credentials and then uses that to access resources they are allowed to. This is how many modern applications operate.
If each user has their own database then you can simply store the connection string encrypted locally, as this will be enough to prevent most problems, except for malicious people with access to the users' machine.
Obviously, as Vladimir said, you can take this as a general solution (encrypt it in the config and hope for the best), but I really don't recommend this if any security is required. For example, if you are storing user passwords in the database - even in hashed form - this is not a secure idea. The risk you'll run with using this method for everyone is that somebody could steal all of your data, or wipe all of your data, or even manipulate the data to their advantage.