The credential store in web.config (described in the articles How to use web.config as credential store with Forms Authentication in ASP.NET and How to hash ASP.NET Forms Authentication passwords in web.config in C# ) is useful for simple scenarios only.  You have not use web.config as the credential store, because:

Potential lack of security: Even though users aren’t able to directly request the web.config file, you may still prefer to use a storage medium where you can secure access more effectively. As long as this information is stored on the web server,  passwords are accessible to any administrator, developer, or tester who has access.

No support for adding user-specific information in cases when you want to store information such as addresses, credit cards, personal preferences, and so on.

Poor performance with a large number of users: The web.config file is just a file, and it can’t provide the efficient caching and multiuser access of a database. Whenever you change the web.config file, the HttpApplication is restarted, which results in losing all AppDomains, Session state, and so on. Reestablishing all these things affects performance.

Based on described reasons, in most ASP.NET applications, you will prefer to use your own custom credential store for user name and password combinations, and mostly it will be a database such as SQL Server.  The following example demonstrates this, and it assumes that you have written a function MyAuthenticate that connects to a SQL Server database and reads the corresponding user entry. It returns true if the entered user name and password match the ones stored in the database.

 

protected void LoginAction_Click(object sender, EventArgs e)

{

Page.Validate();

if (!Page.IsValid) return;

if (this.MyAuthenticate(UsernameText.Text, PasswordText.Text))

{

FormsAuthentication.RedirectFromLoginPage(UsernameText.Text, false);

}

else

{

LegendStatus.Text = “Invalid username or password!”;

}

}

 

Fortunately, ASP.NET provides a ready-to-use infrastructure as well as a complete set of securityrelated controls that do this for you. The membership API includes a SQL Server-based data store for storing users and roles, and has functions for validating user names and passwords against users of this store without knowing any details about the underlying database.