Securing Connection Strings 

Protecting access to your data source is one of the most important goals of a secure application. To help limit access to your data source, you must secure connection information such as user ID, password, and data source name. Storing a user ID and password in plain text, such as in your source code, presents a serious security issue. Even if you supply a compiled version of code contain user ID and password information to an external source, your compiled code can be disassembled and the user ID and password exposed by using the MSIL Disassembler (Ildasm.exe) tool. As a result, it is imperative that critical information such as a user ID and password not exist in your code.

Specifying Windows Authentication (Integrated Security)

We recommend that you use Windows Authentication, commonly referred to as integrated security, to connect to server databases. The syntax employed in the connection string varies by provider. The following table shows the syntax used with the .NET Framework data providers.

Note that Integrated Security=true throws an exception when used with the OleDb provider.

Each of the .NET Framework data providers supports different syntax for connection string keywords, making constructing valid connection strings difficult if done by hand. To address this problem, ADO.NET 2.0 introduces new connection string builders for each .NET Framework data provider, which eliminates the guesswork when creating syntactically valid connection strings. For more information, see Building Connection Strings.

Security Note

Setting the Persist Security Info keyword to true or yes in a connection string will allow security-sensitive information, including the user ID and password, to be obtained from the connection after the connection has been opened. If you must supply a user ID and password when making a connection, you are most protected if that information is discarded after it is used to open the connection, which happens when Persist Security Info is set to false or no. This is especially important if you are supplying an open connection to an untrusted source or persisting connection information to disk. Keeping PersistSecurity Info as false helps ensure that the untrusted source does not have access to the security-sensitive information for your connection and also helps ensure that no security-sensitive information is persisted to disk with your connection string information. Persist Security Info is set to false by default.

Using Universal Data Link Files

It is possible to supply connection information for an OleDbConnection in a Universal Data Link (UDL) file; however you should avoid doing so. UDL files are not encrypted, and expose connection string information in clear text. Because a UDL file is an external file-based resource to your application, it cannot be secured using the .NET Framework.

Storing Connection Strings in Configuration Files

To avoid storing connection strings in your code, you can store them in the web.config file for an ASP.NET application and in the app.config file for a Windows application. For more information, see Storing and Retrieving Connection Strings. Connection strings stored in configuration files can also be encrypted. This process is described in How To: Secure Connection Strings When Using Data Source Controls and How To: Secure Connection Strings when Using Data Source Controls (Visual Studio).

Constructing Connection Strings from User Input

If you take connection string information from an external source, such as a user supplying a user ID and password, you must validate any input from the source to ensure that it follows the correct format and does not contain additional parameters that affect your connection. One way to do this is to use the ConnectionStringBuilder classes for the .NET data providers. For more information, see Building Connection Strings, Storing and Retrieving Connection Strings and Validating User Input.

Using Protected Configuration to Encrypt Connection Strings

The Protected Configuration feature can be used to encrypt sensitive information, including user names and passwords, database connection strings, and encryption keys, in a configuration file such as the Web.config file for an ASP.NET application, or the App.config file for a Windows application. See Encrypting Configuration Information Using Protected Configuration, Encrypting and Decrypting Configuration Sections, and Walkthrough: Encrypting Configuration Information Using Protected Configuration.

Encrypting SQL Server Connections

SQL Server 2005 supports two types of encryption: Secure Sockets Layer (SSL), which is enabled in Microsoft SQL Server after installing a certificate, and Internet Protocol Security (IPSec) which is provided by the operating system and is not configured in SQL Server. You can enable encrypted connections by installing a certificate for the Database Engine using the SQL Server Configuration Manager. The server and client computers must have been issued a root certificate from the same certification authority. You do not need to make any changes in your connection string. For more information, see "Encrypting Connections to SQL Server" and "How to: Enable Encryption Connections to the Database Engine" in SQL Server 2005 Books Online.

See Also

Tasks

How To: Secure Connection Strings When Using Data Source Controls

Concepts

Cryptography and Data Access

Other Resources

Securing ADO.NET Applications
Working with Connection Strings