It seems to me that aspnet_regiis -pef ... does absolutely nothing to protect my connection strings. Forget about sql injection, you can have my server. Run that code and I get the password and username in clear text.

This seems to be a big problem to me. Even in my connection string has been encrypted if someone gains access to my server they can also get access to my database. Is there something I am missing here?

Jaime Weise

 see if this helps you out

http://msdn2.microsoft.com/en-us/library/ms178372(VS.80).aspx 

I don't think you understand the problem. I already encrypted my appliction using aspnet_regiis -pef connectionStrings... so on.

The problem is that if you encrypt the page and then place a test page with the code I posted you will be able to see that "encrypted" connection string in clear text password and all. Try it if you have an encrypted connection string in your web.config. This means that if anyone can place a page on your server through an attack or otherwise, that person can easily get your database information and do anything they want with it. My server exists on a different machine as my Sql Server. I was kind of thinking that I need to somehow use windows integrated security to eliminate the config problem but I don't know what that takes or if it is possible accross machines.

 Jaime

Hi Jaime,

    I'm sorry i misunderstood your requirement. I believe you want to prevent users who run the above script from seeing the connection string right?

Well here is some info

Encrypting the connection string in Web.config was intended to prevent System Administrators(or any person with access to the server) from accessing the DB with the username and password specified in the web.config or Disgruntled employees from using web.config to hack the Database.  ASP.Net decrypts that portion of web.config when it loads the application. (The reason why the code shows u the username/password when the application is run.)

And believe me... If anyone was able to run some kinda script in your server you better pray that he doesn't know what he's doing!!!!!

here is another simple script to pull the connection string or the entire app settings.

dim i as integer

for i=0 to appsettings.count

    label.Text = " " & label.Text & " " & AppSettings(i)

next i

sorry couldn't resist

Regarding a possible solution

I think what you can use is Integrated Authentication with Trusted connection (connection string)

http://msdn2.microsoft.com/en-us/library/bsz5788z.aspx

This would take the user's logged in credentials to connect to the DB. So the connection string doens't have the username/password

If your Web Server is different from SQL server make sure you take a look at couple of similar articles and choose the one that most suits your architecture.

hth

Oops posted it twice.

So basically, this is a false sense of security for a inexperienced developers and a stop-gap for bad hackers. 

Anyways, I guess I was right in my assumptions. I just don't see any real form of protection here. Weird! Thanks for the input.

 Jaime

 Depends on how you look at it...

If you're trying to prevent your sql username/password from being displayed when running a particular script, then encrypting web.config is not the answer.

Like I said encrypting web.config was meant for system admin or anyone who has access to the folders on you server from opening the web.config to read the username/password and connect to the DB and mess with it. This is the same reason why some people encrypt the password column in the database. Coz any developer can run a query and get the password. This is critical when it comes to financial application or other business critical applications.

Now if some miscreant (internal or external) is able to run a script on your server.. Then your server is essentially hacked!

So in your case it should be to prevent users from running any kind of scripts on the server. Put the server behind a DMZ, restrict the number of users who have access to the server, there are other stuff which ur system admin can guide you on securing the server. 

Did you try out integrated authentication.... ur script will not show u the user name/password If your connection string uses "Trusted connection" 

 I know this is an older post, but I had to say something about this passage, since it can easily be incorrect if it is not fully understood.

sandeepantony said: Like I said encrypting web.config was meant for system admin or anyone who has access to the folders on you server from opening the web.config to read the username/password and connect to the DB and mess with it.

First a system admin, often has access to the server directly, and this will not prevent him or her from easily decrypting the web.config file.  Obviously, if the system admin, or other user has access to the files on the server, they can, as mentioned above, put in a simple aspx file that would show the decrypted value (although, they would have to figure out the connectionString name, but that's not too difficult for someone with the right skills). If the system itself has privileges to write to the asp.net folder where web.config resides (I highly recommend against this in most scenarios), then a script could be put in that would programmatically decrypt the entire web.config file and not just its individual values.  So, in that scenario, it's not necessarily secure. 

In a way, it's just like putting locks on your doors won't keep out a determined thief.  Most thieves could pick a lock in a few seconds, and those that don't could easily use a glass cutter or baseball bat to get in through your windows or sliding glass door.  The main reason we lock our doors is to keep the honest people honest by not tempting them with easy pickings.  Encrypting the web.config is similar in this regard.  Because it makes it more difficult to figure out what the values are, people who are basically honest, won't be tempted to take that information.

In my humble opinion, the main reason for encrypting the web.config file is as a precaution against a person who manages to gain read access to the web directory, or a copy of the web.config file (in its encrypted state).  For all intents and purposes, the web.config file can only be decrypted on the server in which it resides, so a malicious hacker would have to at least have write access to the web directory, or some sort of access to the encryption key on the server in order to decrypt the file.

If you can use integrated security, that would be better (in terms of security, anyway), but if that is not an option, it is certainly a good idea to encrypt the connection strings, along with any other data sections that might contain sensitive information such as membership provider sections that require a username and password in order to check user credentials, etc.

Hopefully this will help clarify the situation