2

I just got myself in a new company where they develop Windows Forms applications using .NET technologies and VB.NET, Of course. They use SQL Server databases. The BIG issue is that they store the plain text of Connection String. This is obviously really dangerous. Becuase .NET application generates a Settings file within the application and a user can open that file in Notepad. What's the best secure practice for this? Yes. We can store the Connection String inside the code but sometimes the connection String could change.

Thanks for the help.

|improve this question
  • 1
    Secure from whom? Is everyone sharing one login or is there one username per user? Can you not use kerberos / integrated authentication? – Neil McGuigan Nov 25 '15 at 19:09
  • you're referring to web.config right? – KDEx Nov 25 '15 at 19:12
  • That's the worst part its the Settings file included in the .NET Application its Windows Forms, Not its not ASP.NET Page. And the most worst part. There's only one login and it's the admin login to all the database of all the server. So this means, NO ROLES NO LOCKS Just one ADMIN user... – NathanWay Nov 25 '15 at 19:17
  • Why are you using SQL Server authentication instead of Windows Authentication for your database connections? That's the most obvious solution rather than trying to obfuscate the password somewhere. – Steve Sether Nov 25 '15 at 21:23
4

You have a couple options.

The first, and preferred, would be to establish a web services layer that the application calls instead of going to the database directly. This, obviously, is going to take a bit of time to build. However it would mean you could put your DB behind a firewall that only the web services layer could get through.

The second would be to use encrypt the database access portion of the app.config file. More info here: https://msdn.microsoft.com/en-us/library/zhhddkxy.aspx

The third option, which you would use in combination with the above options, would be to remove all direct sql queries from the app and replace them with calls to stored procs that require a userid or user token parameter. Then each proc would check that the id/token was valid for the given action prior to running it. At the same time you would change the database rights such that only stored procs could be executed.

A fourth option is to implement SSPI in combination with named SQL server users (whether active directory or otherwise). This would mean adding however many users (or user groups) to your database server. The upside is that you could control on an individual basis who had rights to log into the DB server AND you wouldn't have a username/password combo in the app.config file. The downside is that someone needs to maintain that.

*Bear in mind that even if you use encrypted config sections, the user has to have access to the decryption key. So the only thing this really does is protect the key from people who might read the clear text app.config file. A determined user with access to the computer the application is running on could still pull the connection string info from either the computer memory or by decrypting the section using alternate means.

|improve this answer
  • Another downside of option 4 is that people could potentially access the DB directly via other means and potentially do harm. (SSMS, Excel, etc.) Though that's not to say that my suggested version of your #4 with a shared domain account is inherently better, since the runas requirement has faults of its own... – TTT Nov 25 '15 at 20:07
  • This is kind of funny - blast from the past, and you're still thinking along the same lines: stackoverflow.com/questions/2867075/… – TTT Nov 25 '15 at 20:10
  • @TTT: When you have the right answer, and the mechanisms haven't really changed, then you stick with it. :) – NotMe Dec 1 '15 at 0:09
0

Step 1 (Mandatory): Create a new user for SQL Server which has the minimum set of permissions needed by the application. Whether this new user is a SQL Server Login or Windows Domain User will depend on which option you choose below.

Easiest option: The new user you create in Step 1 can be a SQL Server login. Encrypt the secure parts of the configuration file that contain the credentials. (e.g. the connection string.)

Better option: The new user you create in Step 1 is a Windows user, and you assign permissions for that user to SQL Server using Windows authentication. Now each machine where the application runs from can be configured to run the application as the new user. (There are various ways to accomplish this.) In the config file you now can use Integrated Security for connecting to SQL Server which means you don't have to encrypt it since nothing secure would be displayed.

Note: these options are assuming the WinForms application is running on an internal company network only.

|improve this answer

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.