Web Development

Ask something
Discussion Locked

Store database connection settings

0 helpful
11 replies

by maryweilage 1 view

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

This week's .NET newsletter provides instructions on how to store database connection settings.

In the final paragraph, author Tony Patton says: "In the end, the ultimate decision is yours. You may choose to place the connection string directly within the application if security and maintenance is not an issue. The same is true with the use of a configuration or XML file and registry entries." Please let us know which method you prefer.

If you aren't subscribed to our free .NET newsletter, click the following link to automatically sign up:
http://nl.com.com/MiniFormHandler?brand=builder&subs_channel=bldr_front_door&list_id=e605&tag=fb

11 replies

by wouter

Hi all,
The registry option isn't really the one for us, so we use the web.config. There is only a big risk, that when a hacker is on your box, the string can be read easily.
Is there maybe a secure and easy to deploy way to protect it?

Grtz,

Wouter

by goober bob

I like the encryption, but I still prefer the registry since we often use the same connection across multiple applications.

by goober bob

.NET makes it easy to work with XML documents, so it seems like a reasonable option. My only concern is whether the web.config file will be available (accessed) since IIS does not make it availalbe - by default. Anybody tried this?

by goober bob

Storing the connection information in our Web Server's registry has worked well for us. It provides security and a central location for storing and maintaining the information. One thing we have been contemplating is encrypting the data stored in the registry, but we have not implemented it at this point.

by Tony Patton

The key element within the configuration XML should be contained in an appSettings element like the following:

-Tony.

by fortysomething

I've recently started keeping path information, which is the part of the connection string most likely to change, separate from the user name and password information. Path info can be kept in web.config, and user name and password can be kept whereever needed to meet the security needs of your application.

by john_haefeli

Let's face it.

If someone gains access to your server, there is nothing you can do about security. You can make it harder, but not foolproof.

The hardest way I can think of right now is to encrypt the entire system, including binaries and dated key itself, using full machine image checksum and machine id, and have it decrypted on the fly, which is currently beyond the ability of the OS; the original software would be on a different machine, executables of which would be copied to the executable machine, write permission one time only like reformat, with no reference to the source machine, all writable persistent data being accessed through separate security-dialoged encrypted database sessions.

Good luck!

by spiv

I think the comment about plain-text in the web.config has to do with layered security.

It is quite possible for an application level bug or hack to allow a user access to the file system yet they may not have full server access.

thus, if the connection string is not in the web.config, or is encrypted in the web.config, they will still not be able to penetrate the database.

Even with full server access, if the connection information is encrypted, the hacker will not be able to use the web server as a point of attach to jump onto the database server.

by raakesh.kotecha

Encryption and tighter Security are all fine.

But, how about not giving hints to what these actual 'settings' are for in the first place...

I've yet to see an article on Security which encourages developers to divert the attention of potential hackers away from the really useful data that many developers hold in plain text config files.

Instead of using words such as
"database" , "Connection", "UserID", "PWD" etc which already hint as what these are use generic, ambiguous words such as say: "Screen", "Title", "Xpos", "Ypos" - almost anything that you can come up with that looks like the usual settings...

Obviously as the developer you know what real meaning they hold but 'hackers' will be concentrating on database userid pwd etc !

This discussion is closed to new replies.