Why ASP.NET Passwords Are Vulnerable to Hackers

ASP.NET (in all of its flavors) isn't a bad framework as far as security goes—Microsoft generally does a good job in creating apps that are relatively secure without going through a lot of effort. One area where they have fallen short, though, is in password management. I'll go so far as to say that if you're using the default ASP.NET password and user management functionality, any determined hacker has already gotten in. Think I'm exaggerating? Read on.

Hacking into Your System

Any hacker who wants to get into your system is first going to do high-level research about the system. Who owns it? Who uses it? When do they use it? Who are the likely administrators of the system? What emails do they use—are they available publicly on sites like LinkedIn?

A hacker would then do some research on your specific system. Can users register and gain access? If so, they will create a user and then poke around for potential vulnerabilities. What software is running the website? Very often this is freely available in the headers sent in every response from the server (as is the default in older frameworks), though this is usually easy to figure out even if the web administrators have removed these headers. What server is the system running on? Again, sometimes this information is sent with the request, but it usually can be figured out either way.

Then comes technical research. Are there any known issues with your server or web software? MITRE has two lists—the Common Vulnerability Enumeration (CVE) and the Common Weakness Enumeration (CWE)—which contain publicly available lists of known vulnerabilities in technology products. Tools like metasploit can automatically scan these lists for vulnerabilities associated with your software. And if the hacker looks in the right place, they'll realize that the ASP.NET password management function is vulnerable, and will use tools like cupp and CeWL to generate a list of passwords to hack into your site. Then they will use tools like Burp Suite to automate their attack.

(Of course, there are probably tools available on the black market that do the same thing. I only know about tools frequently used by ethical hackers.)

What's Wrong with ASP.NET Password Management?

On the surface, the ASP.NET password management looks fine. It uses a relatively strong encryption algorithm to store passwords and locks out users if they have five failed login attempts. What's the problem?

1. ASP.NET does not log failed login attempts where the username does not already exist in the system.
2. The ASP.NET logging mechanism, by default, does not log the IP address of the failed login attempt.
3. ASP.NET resets the lockout count back to zero after a period of time has passed (default is 5 minutes).

Assuming you are like most small businesses, you probably don't have a sophisticated web application firewall protecting your site. If that's the case, problem #1 means that there is no penalty for a hacker to try thousands, if not millions, of different usernames against your website. And because of problem #2, if you don't log the IP address of a failed login attempt, there is no way for a website to quarantine the one who is doing the attacking (even if the hacker is caught). And finally, most hackers will try to figure out what the lockout threshold is and stay under it for users they try. In this case, they would limit the number of login attempts to any one account to 4 to help prevent getting caught. But with problem #3, they have no need to do so. Instead, they can keep locking out the user every 5 minutes when that user is not expected to try to log in.

So, to sum up, all a hacker needs to do to get into an ASP.NET website that has the default password mechanisms is to write a script that tries 5 passwords for each suspected account every five minutes when users are not expected to log in. Easy peasy.

What can be done?

To fix this, let's start with the obvious and fix the three problems outlined in the previous section:

1. Log failed login attempts where the username is not in the system. This at least gives you the ability to see if an unusual number of failed login attempts have occurred.
2. Log whatever information you can when a possible hacking attempt occurs, including IP address of the user.
3. When a user has been locked out, remember previous lockouts. If they've been locked out again without a successful login attempt, lock them out for 10 minutes instead of 5. Then make it 20, then 40, and so on.

The system should also be smart enough to lock out requests coming from a source that is failing with too many username/password combinations.

Another thing that can be done is to track the IP addresses of successful logins. If a login attempt comes from a new IP address, ask the user to verify their account by sending a token via email or text, to help prevent hackers from getting in if a password is stolen.

Implementation in My Security Framework

Unfortunately, implementing all of this on your own is easier said than done. To put all these features in, you would need to rebuild and/or replace several components of the ASP.NET framework that developers should be able to take for granted. Fortunately, implementing this with the ASP.NET Security Enhancer framework is fairly easy. To track all of the information you need, use the NCGSignInManager (inside the NCG.Core.Security.Authentication namespace) instead of the Microsoft-built SignInManager. The custom sign-in manager does the work for you. Then add the [BlockIfLockedOut] attribute (in the NCG.Core.MVC.UserLockout namespace) to any controller class or method you would like blocked out if the user behaves suspiciously. (I would recommend locking suspicious users out of more places than not.) Now you're protected from a lot more password-related attacks than you were before. Easy peasy.