Mage_IronWolf's WebLog

Quick thoughts on what we are doing for security with .NET

My work has an initiative to remove all login information from web.config and UDL files. The problem we were facing was that we still had to edit those files when we changed environments. ie., when you move from DEV to QA, you have to change the DB server you were connecting to.

Working with another person here, I developed a 2 level approach for .NET apps.

1 - We are using the built in encryption/decryption in .NET to read a login/password from an encrypted registry setting and have the .NET application impersonate that login. This works well as we are using it to connect it to some HR information.

2 - To deal with the environment issue, I set up a registry setting on all levels of the servers, including DEV, with a single value. It's value is DEV, QA, or PROD. When I need to create a DB connection, I read the registry, determine the environment based on the value and then read out the proper DB connection string from the web.config. The web.config file contains all 3 strings.

Since I am using integrated security, the actual login is hidden. We don't have to worry about someone copying the wrong web.config file into the wrong environment and thus causing issues.

I also connect to a Web Service for some security. We filter certain pages in different applications based on levels of security. I have been able to use the same principal for changing the Web Service URL so that the correct one is being hit.

I am still working out a way to do this with the UDL files, without redoing all of the COM+.

Any comments or ideas would be appreciated.


John Debnam
Programmer/Analyst
Posted: Mar 03 2004, 04:25 PM by Mage_IronWolf | with 3 comment(s)

Comments

Jerry Pisk said:

1) That is security through obscurity, you are not making your login information any more secure than storing it in clear text. If your code can read the encryption key to decrypt its credentials then it's like reading them from clear text. If the attacker manages to read your data then [s]he will manage to read your encryption keys as well. No security added here.

And storing configuration data in the registry has its own issues, there's a reason why even Microsoft is switching to file based configurations.

2) Personally I use logical names to handle this. I only have a single connection string (as in one per connection, no matter what the environment) that points to a database server using a name, such as db.myapp.com. Then I setup hosts file/DNS servers/SQL Server Aliases on each environment to point to the actual server. This way if I make a change to the connection string I make one change, I don't have to remember to change it in all three (or more) places. I don't have to worry about keeping the connection strings the same for each environment. Believe me, it's a lot easier than reading a value from a registry and having several connection strings that should be the same except for the server name.
# March 3, 2004 5:32 PM

Johnny Hall said:

The involvement of the registry sends shivers down my spine.
# March 3, 2004 6:13 PM

TrackBack said:

^_^,Pretty Good!
# April 10, 2005 6:26 AM
Leave a Comment

(required) 

(required) 

(optional)

(required)