ADO.NET 2.0 Security Guidelines - Authentication

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Chaitanya Bijwe


If Possible, Use Windows Authentication

If you can, use Windows authentication when your application connects to SQL Server or other databases that support Windows authentication. Windows authentication offers the following security advantages as compared to SQL authentication:

  • Accounts are centralized and managed by your Active Directory or local authority store.
  • Strong password policies can be controlled and enforced by your domain or local security policy.
  • Passwords are not transmitted over the network.
  • User IDs and passwords are not specified in database connection strings.

The following example uses Windows authentication with the ADO.NET data provider for SQL Server.

SqlConnection pubsConn = new SqlConnection(
   "server=dbserver; database=pubs; Integrated Security=SSPI;");

The following example uses the ADO.NET data provider for OLE DB data sources.

OleDbConnection pubsConn = new OleDbConnection(
  "Provider=SQLOLEDB; Data Source=dbserver; Integrated Security=SSPI;" +
  "Initial Catalog=northwind");

For more information, see "How To: Connect to SQL Server Using Windows Authentication in ASP.NET 2.0," at

If You Use SQL Authentication, Use Strong Passwords

If you use SQL Server authentication, make sure that you use a least-privileged account with a strong password to prevent an attacker from guessing your account's password. A strong password should be at least seven characters in length and contain a combination of alphabetic, numeric, and special characters.

Avoid using blank passwords and the sa account as shown in the following connection string.

SqlConnectionString = "Server=YourServer\Instance; Database=YourDatabase; uid=sa; pwd=;"

Note In SQL Server 2005, you can enable an account option to require strong passwords and the server will check passwords against the server operating system password policy.

If You Use SQL Authentication, Protect Credentials on the Network

If your application is not located in a physically secure isolated data center and you use SQL authentication, you should use Internet Protocol Security (IPSec) or Secure Sockets Layer (SSL) to create an encrypted communication channel between the Web server and database server. When you connect to SQL Server with SQL authentication, the credentials are not encrypted prior to transmission across the network. If you do not secure your network channel with IPSec or SSL, an attacker can easily capture credentials by using a network monitor.

Use SSL when you need granular channel protection for a particular application, instead of for all applications and services running on a computer. If you want to secure all of the IP traffic between the Web and database servers, use IPSec. You can also use IPSec to restrict which computers can communicate with one another. For example, you can help protect a database server by establishing a policy that permits requests only from a trusted client computer, such as an application or Web server. You can also restrict communication to specific IP protocols and TCP/UDP ports.

Note During login, the SQL Server client encrypts the login packet by using SSL if the server has a certificate available. This occurs regardless of whether encryption is enabled for the connection.

If You Use SQL Authentication, Protect Credentials in the Configuration Files

To protect credentials in configuration files, place connection strings inside the <connectionStrings> section, and encrypt them by using the Aspnet_regiis.exe tool. For more information, see the section "Store Encrypted Connection Strings in Configuration Files," in this document.

Consider Which Identity to Use to Connect to the Database

When you connect to a database by using Windows authentication, you need to consider which account to use. Regardless of the account, make sure that it has limited permissions in the database to minimize the damage that can be done should the account be compromised or if an attacker manages a successful SQL injection attack. When using Windows authentication to connect to the database, do the following:

  • Use a trusted service account where possible. This is usually your application's process account. By using a single trusted service account, your application benefits from connection pooling, which provides greater scalability. Also, account administration and authorization within the database is simplified.
  • If you cannot use a domain account, consider mirrored accounts. If you cannot use domain accounts because of domain trust or firewall restrictions, consider using mirrored service accounts instead. With this approach, you still use Windows authentication, but you create two local accounts with the same name and password on the Web server and database server. You configure your application to run using the local account created on the Web server and create a SQL login for the local account on the database server. With this approach, you must make sure that the passwords of the two accounts are synchronized.
  • Use impersonation and delegation when necessary. If you need per-user authorization in the database or if you need to use operating system auditing to track the activity of individual users, use impersonation and delegation and access the database by using the caller's identity. This approach has limited scalability because it prevents the efficient use of connection pooling.
Personal tools