ASP.NET Security Inspection Questions - Authentication

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Jason Taylor, Rudolph Araujo

Authentication Vulnerabilities and Implications



Weak passwords

Passwords can be guessed and dictionary attacks can increase.

Clear text credentials in configuration files

The application is susceptible to SQL injection attacks.

Reliance on client-side validation

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.

Authentication is the process of determining caller identity. Many ASP.NET Web applications use a password mechanism to authenticate users, where the user supplies a user name and password in an HTML form. When you review authentication code, determine whether user names and passwords are sent in plain text over an insecure channel, analyze how user credentials are stored, examine how credentials are verified, and see how the authenticated user is identified after initial logon. Table 4 lists the authentication vulnerabilities and their corresponding security implications.

The following questions can help you to identify vulnerable areas:

  • Does the code enforce strong user management policies?
  • Does the code restrict the number of failed login attempts?

Does the code enforce strong user management policies?

To determine if the application enforces strong user management policies, consider the following questions:

  • Does the code enforce password complexity rules?

If the application uses the membership system, check the values of the following attributes to make sure that the code enforces strong passwords:

  • passwordStrengthRegularExpression. The default is "".
  • minRequiredPasswordLength. The default is 7.
  • minRequiredNonalphanumericCharacters. The default is 1.

Note These default values are for the SQL Server and the Microsoft Active Directory® directory service membership providers. First, the SQL Server and Active Directory providers compare the password to the minRequiredPasswordLength and minRequiredNonalphanumericCharacters attributes. If the regular expression is intended to be the authoritative match, then the other two attributes should have weaker values, such as a minimum length of 1 and 0 non-alphanumeric characters.

If you do not use ASP.NET membership, verify that the code used to create new user accounts ensures that passwords meet appropriate strength requirements.

  • Do you store passwords in code or in configuration files?

Verify that your code does not contain hard-coded passwords. Search for text strings such as "password" and "pwd".

Does the code restrict the number of failed login attempts?

You should consider locking out accounts if a set number of failed logon attempts is exceeded. If you use the SQL membership provider, verify that you have set the following attributes in your provider definition.

  • maxInvalidPasswordAttempts. This defines the number of failed password attempts or failed password answer attempts that are allowed before locking out a user's account. When the number of failed attempts equals the value set in this attribute, the user's account is locked out. The default value is 5.
  • passwordAttemptWindow. This defines the time window, in minutes, during which failed password attempts and failed password answer attempts are tracked. The default value is 10.

Note If you use the default values, and there are 5 failed login attempts within 10 minutes, the account is locked out.

Personal tools