Click here to Skip to main content
Email Password   helpLost your password?

Introduction

In developing ASP.NET applications, we make heavy use of Web.Config to store and retrieve database connection strings. But we need to be aware of the fact that Web.Config is a simple XML text file and its contents are readable by any user having access to the the webserver's file system. Albeit the fact that accesses like http://localhost/deepak/web.config etc. are halted by the webserver with a message 'The type of page is not served', anybody with console access to the system can still open and read the database connection strings, which might contain the password to the database in an unencrypted manner.

Simple encryption

After a great deal of search in MSDN and other sites, I found a simple way to encrypt strings using a minimum of 8 character string (8 characters should be okay since even MSN Hotmail recommends a minimum of 8 character passwords for all accounts). Sections have been taken from ASPAlliance example but the method has been kept as a static method for the simple reason that you need not create object for every encryption and decryption strategy.

The attached example makes use of DESCryptoServiceProvider that is available in System.Security.Cryptography namespace.

Enhancement

For example sake, I have given both the key and the encrypted string in web.config. But for security reasons, it would be advisable to keep the key elsewhere in the file system and read the key dynamically from this file from the specified location. Additional care has to be taken that the place where we store the key is accessible only to System Administrators and other authorized personnel. With this strategy and trick in place, the database connection string could be made relatively safe for a particular web application.

How to use the example

Include the following two lines in web.config:

         <add key="cKey" value="LavanyaDeepak"/>
         <add key="cDb" value="C0AHny7FDFewTPE7eTp5RA=="/>

To any of your test applications, unzip the files in the archive (Cryptography.cs and Test.Aspx and Test.Cs). Include them in a project in Visual Studio .NET. Build the application and run test.aspx from the web browser.

Conclusion

I hope the above article would be very useful for .NET developers worldwide to make effective and secure use of database connection strings that are put in Web.Config. Many thanks to developers whose ideas and pieces of code have been helping me out in drafting these static methods.

You must Sign In to use this message board.
 
 
Per page   
 FirstPrevNext
GeneralDeveloper Caste System
shitba
6:12 13 Jan '06  
I always love it when developers who have full control over their web servers(Brahmins) are hyper-critical of us poor losers in the shared hosting realm(Untouchables). We CAN'T use a trusted connection to the database. We CAN'T set NTFS permissions of ANY kind. We can't even store an encryption key on a secure part of the machine because we don't have access to that!

As a result, we're left with options of code obfuscation, and weak encryption/decryption processes. Far from perfect, but what do you want for $20/month? Laugh




Mikeymac
GeneralThe encryption code
durayakar
17:41 12 Nov '03  
If you have deployed the encrypt/decrypt function/component on the web server, the person who hs access to your web site folder can add a very simple aspx page and/or piece of code to your web site and call the very same function to decrypt the connection string...

I also do not see any increased "security" by encrypting the connection string if the decryption code is on the same hosting environment... If the person has access to the web site folder, he has full access to the compiled and ready-to-use decryption code as well...

I also do not see any further security in the user access stuff... If the suspect has access to your web site folder, he will be able to run his code under your asp.net account, in other words under the very same identity that your web site code runs under...

So, this conection string will remain to be vulnerable to be compromised by the web site admin that has access to your web site folder directly.

Regards..

Duray AKAR

f=m.a
GeneralRe: The encryption code
Vasudevan Deepak Kumar
17:47 12 Nov '03  
Yep! You are right, Duray Akar.

That particular folder containing the decryption info needs to be in a password-protected folder. Is'nt it?



Deepak Kumar Vasudevan
Personal Web: http://www24.brinkster.com/lavanyadeepak/default.asp I Blog At: http://deepak.blogdrive.com/
Generalhmm ...
krumpo
1:52 28 Jan '03  
Yet another example of "security" by obscurity ... Protecting your key file is exactly the same problem as protecting web.config itself so cryptography is useless here and you can keep that connection string in plain text.

Suggestions: either keep safe your web.config or deploy database provided (and dependant) way of authenticating ASP.NET worker process - at least both Oracle and MS SQL Server have that ...

PS: maybe just I don't see the light Smile
GeneralRe: hmm ...
Enki42
15:10 30 Jan '03  
Another problem with it is that it decreases performace of the app since then it must decrypt the string each time its needed.

Just use intergrated login on SQL server and give logon access to the user the asp page is running under.

So basically what krumpo said....
GeneralRe: hmm ...
Deepak Kumar Vasudevan
17:42 30 Jan '03  
Hi Enki,

That would be a poor idea of decrypting each time. Because we are not going to change ConnectionStrings that frequently. Perhaps here comes the advantage of ASP.NET Caching Strategies.

You can cache the connectionstring and retrieve the item from Cache. If the item is not found in Cache, then read from Web.Config, insert it into Cache and proceed.

Did this solve your problem?

Deepak Kumar Vasudevan
http://deepak.portland.co.uk/
GeneralRe: hmm ...
Enki42
2:22 31 Jan '03  
Ok, so a jumped a bit on the speed issue, but that doesn't change the fact that its still insecure because its just security through obscurity which is really the main issue here.
GeneralRe: hmm ...
ThePhoenix
23:20 8 Jul '03  
Agree with the hmm... definitely security through obfuscation. If you want to protect the connection string, then surely the best process is just to set the NTFS permissions on web.config so that only the ASP.NET worker process and any required personnel can access it. This will also protect the other information in web.config (which you probably wouldn't really want people changing).

Now, what is a signature??? Roll eyes
GeneralRe: hmm ...
Anonymous
11:27 22 Feb '05  
when IIS is exploited, it would be ASP.Net account that's being used. Which means the connection string will be only open to the hacker that exploited the system.
GeneralRe: hmm ...
Anonymous
8:19 12 Oct '05  
By default IIS runs under SYSTEM account and aspnet_wp.exe under 'IUSR_xxxxxx' account.
Just revoke any rights for SYSTEM against Web.config.
Even better(worse), impersonation can allow you to run aspnet_wp's worker threads under different win account.
GeneralRe: hmm ...
shahprabal
8:26 4 Jan '06  
Its simple really :

- Encrypt your conn string and paste it in web.config
- Decrypt the string in your web app using the key and provided class

Comprende?

OFCOURSE if you compile that test program and keep it in the same directory AND keep the key there as well then IT BEATS THE PURPOSE DOESN'T IT?

Maybe author should have mentioned that not being a moron is a prerequisite !

Laugh
GeneralCool Idea
Heath Stewart
5:56 26 Jan '03  
I never really thought of this since the Web.config isn't visible by default to anonymous users, but larger companies have to be weary of their own people. This is a really good idea.

"Well, I wouldn't say I've been missing it, Bob." - Peter Gibbons


Last Updated 26 Jan 2003 | Advertise | Privacy | Terms of Use | Copyright © CodeProject, 1999-2010