Secure your connection strings

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan

If you need to use SQL authentication, then your connection contains the user name and password. If an attacker exploits a source code disclosure vulnerability on the Web server or manages to log on to the server, the attacker can retrieve the connection strings. Similarly, anyone with a legitimate login to the server can view them. Secure connection strings using encryption.

Contents

Encrypt the Connection String

Encrypt connection strings by using DPAPI. With DPAPI encryption, you avoid encryption key management issues because the encryption key is managed by the platform and is tied to either a specific computer or a Windows user account.

Note If you are running .NET 2.0, you can use the Protected Configuration feature for encrypting the connection string. For more information on encrypting the connection string, see "How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI" at http://msdn.microsoft.com/library/en-us/dnpag2/html/PAGHT000005.asp and "How To: Encrypt Configuration Sections in ASP.NET 2.0 Using RSA." at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/PAGHT000006.asp

If you are running .NET 1.1, to use DPAPI, you must call the Win32 DPAPI functions through P/Invoke.

For details on how to build a managed wrapper class, see "How To: Create a DPAPI Library" in the "How To" section of "Microsoft patterns & practices Volume I, Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication" at http://msdn.microsoft.com/library/en-us/dnnetsec/html/secnetlpMSDN.asp.

Store Encrypted Connection Strings Securely

The encrypted connection string can be placed in the registry or in the Web.config or Machine.config file. If you use a key beneath HKEY_LOCAL_MACHINE, apply the following ACL to the key:

Administrators: Full Control
Process Account: Read

Note The process account is determined by the process in which your data access assembly runs. This is usually the ASP.NET process or an Enterprise Services server process if your solution uses an Enterprise Services middle tier.

Alternatively you can consider using HKEY_CURRENT_USER, which provides restricted access. For more information, see the "Registry" section in Chapter 7, "Building Secure Assemblies." at http://msdn.microsoft.com/library/en-us/dnnetsec/html/THCMCh07.asp

Note If you use the Visual Studio.NET database connection Wizards, the connection strings are stored either as a clear text property value in the Web application code-behind file or in the Web.config file. Both of these approaches should be avoided.

Although it is potentially less secure than using a restricted registry key, you may want to store the encrypted string in the Web.config for easier deployment. In this case, use a custom <appSettings> name-value pair as shown below:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
 <appSettings>
  <add key="connectionString" value="AQA..bIE=" />
 </appSettings>
 <system.web>
  ...
 </system.web>
</configuration>

To access the cipher text from the <appSettings> element, use the ConfigurationSettings class as shown below:

using System.Configuration;
private static string GetConnectionString()
{
 return ConfigurationSettings.AppSettings["connectionString"];
}

Do Not Use Persist Security Info='True' or 'Yes'

When you include the Persist Security Info attribute in a connection string, it causes the ConnectionString property to strip out the password from the connection string before it is returned to the user. The default setting of false (equivalent to omitting the Persist Security Info attribute) discards the information once the connection is made to the database.

References

Personal tools