ASP.NET login controls transmit information to the server in plain text over HTTP. When you are dealing with sensitive information, it is strongly recommended that you use HTTPS protocol with secure sockets layer (SSL) encryption. SSL protects against data being altered (data integrity), protects a user's identity (confidentiality), and assures that data originates from the expected client (authentication). For more information, see Cryptography Overview and Configuring SSL on a Web Server or a Web Site in the IIS documentation.

Never assume that input you get from users is safe. Malicious users can send potentially dangerous information from the client to your application. For login controls, it is especially important to take precautions with user input because the information being entered is often sensitive. For more information about guarding against malicious input, see Basic Security Practices for Web Applications.

Whenever practical, use validation controls to test for valid user names and for strong passwords. You can validate some user input without validation controls. For example, the CreateUserWizard control supports required and comparison validation. You can also specify a regular expression with the EmailRegularExpression property to validate that e-mail addresses match a specified pattern and with the PasswordRegularExpression property to validate that passwords meet your requirements.

For the most flexibility in validating user input in login controls, you can use templates. Whenever possible, create a template for the control, add individual controls (typically TextBox controls), and add validation controls to restrict the user's input to the narrowest allowable input.

Note:
When using validation controls, always perform validation in server code in addition to using client-side validation. This helps prevent users from bypassing validation by disabling or changing the client script check.

For more information, see Validating User Input in ASP.NET Web Pages.

Login controls store information in the page's view state, so it is a best security practice to secure view state. Although view state data is stored in an encoded format, it can be viewed and tampered with. For more information, see ASP.NET View State Overview.

ASP.NET membership provides functionality for validating and storing user credentials. The CreateUserWizard, Login, PasswordRecovery, and ChangePassword controls use ASP.NET membership to enable you to create a complete authentication system that requires little or no code. Additionally, the LoginName, LoginStatus, and LoginView controls can be used to complete your solution for handling user membership and controlling access to pages within your Web site. For more information, see Introduction to Membership and Securing Membership.

Membership providers shipped with ASP.NET have a built-in threshold for the maximum number of invalid password or password answer attempts, as specified in the MaxInvalidPasswordAttempts property. ASP.NET membership also enables you to configure the number of minutes in which a maximum number of invalid password or password answer attempts are allowed before the membership user is locked out, as specified in the PasswordAttemptWindow property. The default password attempt threshold is 5, and the default password attempt window is 10 minutes. Thresholds in the default providers can be overridden by thresholds set in the membership section of the application's Web.config file. It is recommended that if you set these thresholds, you set the values as low as practical. Additionally, it is recommended that you do not set the RequiresQuestionAndAnswer property to false, because invalid password answer attempts will not be tracked. For more information, see Membership Providers.

The CreateUserWizard, ChangePassword, and PasswordRecovery controls can send e-mail messages with details about the completed user transaction. Ensure that any e-mail messages sent to users reveal only necessary information. For example, avoid making the subject line of the e-mail messages easy for unintended parties to filter from other e-mail messages. It is recommended that you avoid sending passwords in e-mail. Consider other methods of verifying password transactions, such as sending a confirmation code and a return URL that requires users to use the URL to complete the transaction.

If the MailDefinition property of the CreateUserWizard, ChangePassword, and PasswordRecovery controls is not specified, then no e-mail message is sent. When these controls are configured to send e-mail messages, it is recommended that you handle the mail error event to catch any SMTP-related errors to avoid revealing unnecessary information to users. For the ChangePassword control, handle the SendMailError and set the Handled property of the SendMailErrorEventArgs object to true. For an example that shows how to handle a mail error event, see SendMailError event. For more information on installing the Simple Mail Transfer Protocol (SMTP) service, see How to: Install and Configure SMTP Virtual Servers in IIS 6.0.

The CreateUserWizard control collects information from a user and then creates an account in the ASP.NET membership system for that user. You can extend the CreateUserWizard control to accept additional information by adding fields or steps before or after the CreateUserWizardStep and the CompleteWizardStep steps. A security issue could arise if a user does not complete all the steps in a CreateUserWizard control but an account is created. To prevent users from bypassing custom wizard steps, override the OnNextButtonClick method and perform custom authentication. Once the information is collected, use the MembershipProvider class's CreateUser method to create the user.

If you are performing administrative tasks and are using the CreateUserWizard to automatically create user accounts, it is recommended that you set the AutoGeneratePassword property to true and the LoginCreatedUser property to false. In this particular scenario, setting the DisableCreatedUser property to false is recommended.

The Login control is a composite control that incorporates user name and password text boxes, as well as a check box indicating whether users want to be remembered the next time they visit the page. The RememberMeSet property causes an authentication cookie to be sent to the user's browser and the DisplayRememberMe property displays a check box that enables the user to control whether a persistent cookie is sent. Avoid setting RememberMeSet to true and DisplayRememberMe to false, because a cookie is sent but the user does not know it. In general, there are risks involved in storing cookies on users' computers. Cookies are another form of user input and are therefore subject to information disclosure and spoofing. For more information, see ASP.NET Cookies Overview.

If your Login control is used with a wide range of end users, consider coding the control so that users on public computers have an option of using a non-persistent cookie which is discarded after the session times out. For more information on writing cookies, see How to: Write a Cookie.

The LoginName control displays the user's logged-in name, or it displays the user's domain and account name if the application is using Windows authentication. Consider adding a check box that enables users to specify whether their name or account information is displayed. For example, users on public computers may not want sensitive information displayed.

The LoginView control enables you to display different information to users who are logged on and to users who are not logged on (anonymous users). Review the contents that you display with the AnonymousTemplate LoggedInTemplate templates, and any with templates associated with the RoleGroups property to ensure that users are not able to view templates not intended for them. In particular, the collection in the RoleGroups property is searched in the order that templates are defined. The first matching role group template is displayed to the user. If a user is a member of more than one role, the first role group template that matches any of the user's roles is displayed. If more than one template is associated with a single role, only the first defined template will be used. For more information, see Understanding Role Management.

The PasswordRecovery control enables users to retrieve their passwords based on the e-mail addresses associated with their user names. When configuring the PasswordRecovery control, follow these guidelines:

• Handle the SendMailError event to take action if errors occur when sending the e-mail message.

• Set a limited number of password answer attempts with the MaxInvalidPasswordAttempts property and a limited time window with the PasswordAttemptWindow property.

• Review all information sent to users e-mail and review the security of the channel used to transmit messages, especially if the password recovery e-mail message contains user passwords. Avoid sending e-mail messages that are clearly marked as containing sensitive information, such as messages in which the subject line contains the word "password".

The ChangePassword control enables users to change their passwords. When configuring the ChangePassword control, follow these guidelines:

• Handle the SendMailError event to take action if errors occur when sending e-mail.

• Set a limited number of password answer attempts with the MaxInvalidPasswordAttempts property and a limited time window with the PasswordAttemptWindow property.

• Review all information sent to users e-mail and review the security of the channel used to transmit messages, especially when the ChangePassword control is configured to use e-mail to send the new password to the user.

• Use SSL to ensure that the user's new password cannot be read during the postback.

• Limit access to the file that the ChangePassword control uses as the body of e-mail messages sent to the user. This file is defined by the MailDefinition class's BodyFileName property.