There are several causes for this. The most widely recognized are as follows:

This is perhaps the more popular attack of all, since it's very usual to find it in literature and movies about hacking (often over exaggerated, let's say).

It is usually seen next to other techniques of the so-called social engineering, which is defined by Wikipedia as follows:

Many well-known hackers, such as Kevin Mitnick, are considered real masters in this art (he runs a cyber security company of his own now).

Of course, in the OWASP initiative, we can find abundant information about the best ways to cope with this threat depending on different scenarios.

In .NET programming, we have a bunch of possibilities to enforce security authentication and authorization as well as many other options, including special namespaces dedicated to security (System.Security) and cryptography (System.Security.Cryptography).

publicstaticbyte[] HashPassword(string password)
{
 var provider = newSHA1CryptoServiceProvider();
  var encoding = newUnicodeEncoding();
  return provider.ComputeHash(encoding.GetBytes(password));
}

publicstaticbyte[] HashPassword256(string password)
{
  SHA256 mySHA256 = SHA256Managed.Create();
  var encoding = newUnicodeEncoding();
  return mySHA256.ComputeHash(encoding.GetBytes(password));
}

When talking about the old ASP.NET Web Forms applications, the truth is that they implement security pretty well (all in the server):

However, in ASP.NET MVC, most of this functionality is not present. So, we have another set of choices to ensure these features.

To start with, when you create a new ASP.NET MVC application, you are offered some choices about authentication:

The second choice (individual accounts) allows the user to authenticate via Facebook, Twitter, or Google accounts (or even another security mechanism).

The third choice is for applications that authenticate users with Active Directory, Microsoft Azure Active Directory, or Office 365. You can choose single or multiple organizations or on-premises infrastructure, as shown in the next screenshot:

Of course, in Windows Authentication, all users logged into the system are allowed to get in.

In case you opt for an individual authentication, the prototype project that Visual Studio creates for us gives us some clues about how to code it correctly.

If you take a look at the default project, you'll see there are several classes that implement all the management about identities, passwords, and so on. This is included in the ManageControllers.cs file, which is generated by the default project.

The preferred measure to take in this case is the use of attributes in those controllers that might compromise security. Attributes for authorization allow you to configure who's allowed to use the corresponding controller (or the action method if you want to get more granular control).

This code explains how to implement several security features:

This attribute allows some customization by the programmer: you can indicate specific roles, specific users, or both, as shown in the following screenshot:

Besides these measures, a look at the AccountController class shows several methods that are marked with security attributes as well. The class itself is marked with AuthorizeAttribute, but we find some methods marked with [AllowAnonymous] too. The reason is because some actions and controllers are skipped by AuthorizeAttribute during authorization and are intended to allow initial access to these methods.

As for the second way to authenticate, that is, via external logins provided by Google, Twitter, or Facebook, this is now possible thanks to OAuth and OpenID, two standards for authentication widely used in social networks.

The protocols associated with these standards were not easy to implement in the past because they are complex; also, some top providers are used to implement them with some differences. Fortunately, the MVC project template eases the way we can manage these options.

The following (commented) code appears just like this in the project in order to allow you to code these new options with these external providers (you'll find them in the Startup.Auth.cs file):

// Uncomment the following lines to enable logging in with third party
//login providers
//app.UseMicrosoftAccountAuthentication(
//  clientId: "",
//  clientSecret: "");

//app.UseTwitterAuthentication(
//  consumerKey: "",
//  consumerSecret: "");

//app.UseFacebookAuthentication(
//  appId: "",
//  appSecret: "");

//app.UseGoogleAuthentication(new GoogleOAuth2AuthenticationOptions()
//{
//   ClientId = "",
//  ClientSecret = ""
//});

As you can see, each provider requires some kind of user and password combination, which you can save in the storage media selected for this purpose.

Finally, note that there are other attributes in relation to security that you might use: for example, you can force a callback from an external provider in order to use HTTPS instead of HTTP by adding the [RequireHttps] attribute, which is linked to the critical action method you want to protect.

In this manner, you have an extra layer of security with just a single attribute.