Forms authentication is an attractive option for you, for the reasons that:
– You have full and complete control over the authentication code – because is implemented entirely within ASP.NET. You don’t need to rely on any external systems, as you do with Windows or Passport authentication.
– You have full control over the appearance of the login form – because you can format the login form in any way you like. This flexibility in appearance is not available in the other authentication methods. If you don’t want to do any of this work, you can use the higher-level membership API and the ASP.NET security controls. These security controls contain a ready-to-use and highly customizable Login control.
– It works with any browser – because uses standard HTML as its user interface, so all browsers can handle it. Since you can format the login form in any way you like, you can even use forms authentication with browsers that do not use HTML, such as those on mobile devices. To do this, you need to detect the browser being used and provide a form in the correct format for the device.
Forms authentication also has the following disadvantages:
– You have to create your own login interface – you can either create the login page completely on your own or use the ASP.NET security controls. Other forms of authentication supply some prebuilt portions.
– You have to maintain a catalog with user credentials – because, you are responsible for maintaining the details of the users who access your system. All these considerations don’t apply to most other types of authentication. The most important details are the credentials that the user needs in order to log into the system. Not only do you need to devise a way to store them, but you also need to ensure that they are stored securely. Also, you need to provide some sort of administration tools for managing the users stored in your custom store.
– You have to take additional precautions against the interception of network traffic – because when a user enters credentials for forms authentication, the credentials are sent from the browser to the server in plain-text format. This means anyone intercepting them will be able to read them. This is obviously an insecure situation.
The usual solution to this problem is to use SSL. You can configure forms authentication to encrypt and sign the cookie, and therefore it’s extremely difficult for an attacker to get any information from it. In addition, the cookie should not contain any sensitive information and therefore won’t include the password that was used for authentication.
But what if the attacker intercepts the unencrypted traffic and just picks the already encrypted cookie and uses it for replay? The attacker doesn’t need to decrypt it; he/she just needs to send the cookie with his/her own request across the wire. You can mitigate such a replay attack only if you run the entire website with SSL.