Authentication

Examine how your application authenticates its callers , where it uses authentication, and how it ensures that credentials remain secure while in storage and when passed over the network. Vulnerabilities in authentication can make your application susceptible to spoofing attacks, dictionary attacks, session hijacking, and other attacks. Table 5.2 highlights the most common authentication vulnerabilities.

Table 5.2: Common Authentication Vulnerabilities

Vulnerability	Implications
Weak passwords	The risk of password cracking and dictionary attacks increase.
Clear text credentials in configuration files	Insiders who can access the server or attackers who exploit a host vulnerability to download the configuration file have immediate access to credentials.
Passing clear text credentials over the network	Attackers can monitor the network to steal authentication credentials and spoof identity.
Over-privileged accounts	The risks associated with a process or account compromise increase.
Long sessions	The risks associated with session hijacking increase.
Mixing personalization with authentication	Personalization data is suited to persistent cookies. Authentication cookies should not be persisted .

Review the following questions to identify potential vulnerabilities in the way your application performs authentication:

• Do you separate public and restricted access?

• Have you identified service account requirements?

• How do you authenticate the caller?

• How do you authenticate with the database?

• Do you enforce strong account management practices?

Do You Separate Public and Restricted Access?

If your application provides public areas that do not require authentication and restricted areas that do require authentication, examine how your site design distinguishes between the two. You should use separate subfolders for restricted pages and resources and then secure those folders in Internet Information Services (IIS) by configuring them to require SSL. This approach allows you to provide security for sensitive data and authentication cookies using SSL in only those areas of your site that need it. You avoid the added performance hit associated with SSL across the whole site.

Have You Identified Service Account Requirements?

Your design should identify the range of service accounts that is required to connect to different resources, including databases, directory services, and other types of remote network resources. Make sure that the design does not require a single, highly privileged account with sufficient privileges to connect to the range of different resource types.

• Does the design require least privileged accounts?

  Have you identified which resources and operations require which privileges? Check that the design identifies precisely which privileges each account requires to perform its specific function and use least privileged accounts in all cases.

• Does the application need to maintain service account credentials?

  If so make sure that the credentials are encrypted and held in a restricted location, such as a registry key with a restricted access control list (ACL).

How Do You Authenticate the Caller?

Review the following aspects of authenticating a caller. The aspects you use depend on the type of authentication your design uses.

• Do you pass clear text credentials over the wire?

  If you use Forms or Basic authentication, or if you use Web services and pass credentials in SOAP headers, make sure that you use SSL to protect the credentials in transit.

• Do you implement your own user store?

  If so, check where and how the user credentials will be stored. A common mistake is to store plaintext or encrypted passwords in the user store. Instead, you should store a password hash for verification.

  If you validate credentials against a SQL Server user store, pay close attention to the input user names and passwords. Check for the malicious injection of SQL characters .

• Do you use Forms authentication?

  If so, in addition to using SSL to protect the credentials, you should use SSL to protect the authentication cookie. Also check that your design uses a limited session lifetime to counter the threat of cookie replay attacks and check that the cookie is encrypted.

For more information about Forms authentication, see Chapter 10, "Building Secure ASP.NET Web Pages and Controls" and Chapter 19, "Securing Your ASP.NET Application and Web Services."

How Do You Authenticate with the Database?

When your application connects to the database, examine what authentication mechanism you will use, what account or accounts you plan to use, and how you plan to authorize the application in the database.

The following questions help review your approach to database authentication:

• Do you use SQL authentication?

  Ideally , your design uses Windows authentication to connect to SQL Server because this is an inherently more secure approach. If you use SQL authentication, examine how you plan to secure credentials over the network and in database connection strings.

  If your network infrastructure does not provide IPSec encrypted channels, make sure a server certificate is installed on the database to provide automatic SQL credential encryption. Also examine how you plan to secure database connection strings because these strings contain SQL account user names and passwords.

• Do you use the process account?

  If you use the process account of the application and connect to SQL Server using Windows authentication, make sure that your design assumes a least privileged account. The local ASPNET account is provided for this purpose, although with local accounts, you need to create a duplicate account on the database server.

  If you plan to use a domain account, make sure that it is a least privileged account and check that all intervening firewalls support Windows authentication by opening the relevant ports.

• Do you use service accounts?

  If your design requires multiple identities to support more granular authorization in the database, examine how you plan to store the account credentials (ideally they are encrypted using the Data Protection API (DPAPI) and held in a secured registry key) and how you are going to use the service identity.

  Also examine which process will be used to create the impersonated security context using the service account. This should not be done by the ASP.NET application process on Microsoft Windows 2000 because it forces you to increase the privileges of the process account and grant the "Act as part of the operation system" privilege. This should be avoided because it significantly increases the risk factor.

• Have you considered using the anonymous Internet user identity?

  For applications that use Forms or Passport authentication, you can configure a separate anonymous user account for each application. Next, you can enable impersonation and then use the anonymous identity to access the database. This approach accommodates separate authorization and identity tracking for separate applications on the same Web server.

• Do you use the original user identity?

  If your design requires impersonation of the original caller, you need to consider whether or not the approach provides sufficient scalability because connection pooling is ineffective . An alternative approach is to flow the identity of the original caller at the application level through trusted query parameters.

• How do you store database connection strings?

  If database connection strings are hard coded or stored in clear text in configuration files or the COM+ catalog, it makes them vulnerable. Instead, you should encrypt them and restrict access to the encrypted data.

For more information about the different options for connecting to SQL Server and about storing database connection strings securely, see Chapter 14, "Building Secure Data Access."

Do You Enforce Strong Account Management Practices?

The use of strong passwords, restricted login attempts, and other best practice account management policies can be enforced by Windows security policy if your application uses Windows authentication. Otherwise , the application layer is responsible for this. Review the following aspects of the account management of your application:

• Does your application enforce strong passwords?

  For example, do your ASP.NET Web pages use regular expressions to verify password complexity rules?

• Do you restrict the number of failed login attempts?

  Doing so can help counter the threat of dictionary attacks.

• Do you reveal too much information in the event of failure?

  Make sure you do not display messages such as "Incorrect password" because this tells malicious users that the user name is correct. This allows them to focus their efforts on cracking passwords.

• Do you enforce a periodic change of passwords?

  This is recommended because otherwise there is a high probability that a user will not change his or her password, which makes it more vulnerable.

• Can you quickly disable accounts in the event of compromise?

  If an account is compromised, can you easily disable the account to prevent the attacker from continuing to use the account?

• Does your application record login attempts?

  Recording failed login attempts is an effective way to detect an attacker who is attempting to break in.