Click here to Skip to main content
12,293,873 members (66,405 online)
Click here to Skip to main content
Add your own
alternative version


29 bookmarked

Strategy to distribute secure database connection strings in an enterprise environment

, 29 Nov 2003
Rate this:
Please Sign up or sign in to vote.
The article discusses a strategy to securely configure and administer a set of connection strings which can be maintained environment wise. It also talks about distributing this information securely in a huge environment to be used by authorized clients only.


In an enterprise development or deployment effort, we often see a number of clients hitting databases set up for different environments. These clients may be distributed on web servers, admin consoles, reporting servers and others. Generally, developers and architects go crazy maintaining connection strings. This problem is generally circumvented by creating too many logins in the database with restrictive access, copying the same logins and passwords to different environments to make life easier, switching roles in the database or hard coding the connection string in the code - aggravating the issue. If there are a number of environments, the matter gets even worse. Microsoft suggests putting these connection strings in config files and other places. But how secure is it to place this information in the open? If all this sounds too familiar, we all are sailing in the same boat Smile | :)

The following article discusses a simple strategy to maintain and distribute connection strings securely.


An administrator selects a server and uses its registry to host all the connection strings. Every environment, like the system test, development or staging environment can be registered on the server using an admin console shown below.

Start the admin console by using the following command: TestECS.exe -admin

ECS Admin Console

The component, EnterpriseConnString.dll, provided with this article and a keyword set by an administrator, access registry keys on the server which contain the encrypted secure connection strings. The client has to connect to the server and ask for a connection string by an environment which is demonstrated by the following code:

EntConnString connstr = new EntConnString("196.783.45.56");
string connectionString = connstr.GetConnectionString("SystemTest");

A test client is provided with the attached code which can be run using the following command line: TestECS.exe -client. The program runs as shown below:

Sample ECS client


Windows registry on a server is used to maintain encrypted connection strings. The EnterpriseConnectionString component acts as a bridge between the client and the host server. The component contains 3 classes:

  • the encryption/decryption class - EnterpriseConnString.Cypher, uses any crypto provider of choice to encrypt/decrypt the connection strings (I have used DES for demonstration purposes).
  • the EnterpriseConnString.Keyword class retrieves a public key. Location of the public key and its retrieval by this class can be customized. The code provided with the article can read the key from a .NET config file or the local registry.
  • the main class EnterpriseConnString.EntConnString uses both classes mentioned above and deals with the registry keys on the server. This class can be used both by admins and clients. Security is built into the scheme by using Windows authentication and Registry access. An admin has write access to the server registry keys and a client is expected to have read only rights. Even if any client intentionally tries to use the library as an admin, it is expected that Windows authentication prevents the registry from being modified. It is the responsibility of an administrator to maintain this security.


An administrator can install the public key or keyword on every client using a config file or a registry file as deemed fit by the software architect. Using this public key, a set of connection strings for every environment can be created on the server. The clients use the ECS component and call the server using the environment as the index to retrieve the connection string. Here is an example config file: TestECS.exe.config used for the demo.

<?xml version="1.0" encoding="utf-8"?>
<ADD value="12345678" key="keyword">

Security details

To retrieve a connection string, a public key, a server name and the provided component (which contains the private key and the encryption algorithm) are required. In addition to this, the Windows login used by the client needs read permissions on the server to access the registry. The permissions on the registry can be set by using regedt32.exe.

Testing scenarios

The test scenario should test for 3 different types of Windows users.

  • Administrators or users having write permissions should be able to create and read
  • Windows users having only read permissions - should be able to read but not write
  • Others - should not be able to create or read connection strings

Points of interest

To enhance the security, clients may be given a Windows login and password, which has access to the server registry. This makes the administration on the server easy, as all the users need not be added to a group. One set of Windows login and password will suffice. The code inside EnterpriseConnString can be modified to impersonate as this login, when accessing the registry.


This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here


About the Author

Sriram Chitturi
United States United States
No Biography provided

You may also be interested in...

Comments and Discussions

GeneralHELP! Pin
degolove18-May-04 16:43
memberdegolove18-May-04 16:43 
So I'm having a hard time figuring out the answer to these questions:

1) So i've built your library which knows how to get connection strings out of the registry, decrypt them, and return them to my app. Now I need to give a graphics designer access to my .aspx files so they can modify them. Well, since the .aspx files INHERIT from my app... all the designer would have to do is add a <script runat="server">Response.Write(getDecryptedConnectionString());</script> and they'd have it outputteed to the browser. how can you restrict a designer from accessing libraries from the .aspx page when it IS the same as the underlying library?

2) in the end, you have this "123456" key stored in your registry. that's all a good hacker needs to access your library, call the method, pass in this key, and they have the connection string. how do you secure the "123456"? And when you secure that, you'll have a key left over... what do you do with THAT key? Putting it in a config file or hard-coding it into the assembly is the same thing... you can open up either and figure out the key if you really know what you're doing. You can use DPAPI which "does key management for you" (so they say), but it only works per machine/per user (meaning, only machines that encrypted data can decrypt it). So, you can't store an encrypted connection string in a central location and decrypt it on any machine.

any ideas?


General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Terms of Use | Mobile
Web02 | 2.8.160525.2 | Last Updated 30 Nov 2003
Article Copyright 2003 by Sriram Chitturi
Everything else Copyright © CodeProject, 1999-2016
Layout: fixed | fluid