Broken Authentication is the second most critical vulnerability as per OWASP Top 10 list. Using this vulnerability, an attacker can gain control over user accounts in a system. In the worst case, it could help them gain complete control over the system.
In this article, we are going to take a detailed look at the Broken Authentication attack.
To see all the articles from this series, visit the OWASP Top 10 Vulnerabilities page.
Let’s dive in.
The Broken Authentication Vulnerability
Broken Authentication usually occurs due to issues with the application’s authentication mechanism. We are going to discuss some scenarios in which a web application can become vulnerable to it.
If our applications allow any of the following scenarios, then there is a chance that our application could be vulnerable to these types of attacks.
Credential Stuffing and Brute Force Attacks
Using Credential Stuffing, an attacker can automatically inject breached username/password pairs into a website to fraudulently gain access to user accounts. They usually enter a large number of spilled credentials into the application and check if they get a match with an existing account. They could then gain control over that account.
Attackers have hacked many popular websites in the past which include social media platforms, e-commerce websites, and even some financial institutions’ websites. Every time a major password breach occurs, they make the compromised email addresses and passwords available for sale. Hackers or criminal enterprises use this data. Attackers use the leaked credentials for performing credential stuffing.
A brute-force attack is an activity that involves successive attempts of trying various password combinations to break into a website. Attackers submit many passwords or passphrases into the website with the hope of eventually guessing correctly. They can automate this process and systematically check all possible passwords and passphrases until they find the correct one.
Have I Been Pwned is the largest breach database online. We can check if our email was involved in any of the breaches so far in the database. The entire database is downloadable and can be used to be integrated with our existing systems to prevent these kinds of attacks before they even happen. (10GB of passwords! Values are represented as either an SHA-1 or an NTLM hash to protect the original values). You can find more info on Troy Hunt’s blog.
Weak Passwords & Recovery Process
If our application permits default, weak, or well-known passwords, then it will be vulnerable to broken authentication. The first thing an attacker is going to try is common passwords such as ”Password1″ or “admin/admin″.
Similarly, if our application uses weak or ineffective credential recovery and forgot password processes, such as knowledge-based answers, there is a high risk that someone could use that to attack it.
Another thing that we should watch out for is the usage of plain text, encrypted, or weakly hashed passwords. This makes an attacker’s job very easy. We have discussed this in detail in the first part of the series.
Likewise, Multi-factor Authentication is very important while implementing security measures for our application. If we have not implemented that or if the implementation is ineffective, it could make our application vulnerable.
Mismanagement of Session ID
Some applications expose session IDs in the URL. When attackers get hold of a valid session ID, they could easily use that to get into our system.
Similarly, some applications do not rotate session IDs after a successful login. This increases the risk of attack when someone gets hold of the session ID.
Some applications do not properly invalidate session IDs. If we do not invalidate user sessions or authentication tokens (particularly single sign-on (SSO) tokens) during log out or after a period of inactivity, attackers could easily use those to attack our application.
Broken Authentication – Attack Scenarios
In the previous section, we looked at the Broken Authentication vulnerabilities. Now, we are going to look at a few attack scenarios.
Scenario #1
Let’s say an attacker gets hold of a list of leaked credentials. They can perform credential stuffing on our application. If our application does not implement automated threat or credential stuffing protections, they could try those credentials in our application and possibly break into it.
Scenario #2
Imagine our application has a password-based login as the only authentication mechanism and permits weak passwords. Most authentication attacks occur because many websites continue to use passwords as the sole factor for authentication.
Even though the password rotation and complexity requirements were once considered as best practices, today most people use and reuse weak passwords. So, this does not help in securing our web application anymore.
If multi-factor authentication is not implemented and weak passwords are permitted in our application, attackers just need to crack the password and they could get full access to our application.
Scenario #3
Let’s say, session timeouts aren’t set properly for our application. A user uses a public computer to access the application. Instead of selecting the logout option, the user simply closes the browser tab and walks away. An attacker uses the same browser an hour later, the authentication will still be valid and he/she gets access to our application.
If session timeouts are not properly implemented, there is a chance of broken authentication attacks in our system, especially on public shared computers.
Steps to Prevent Broken Authentication Attacks
In the previous section, we looked at some example attack scenarios for Broken Authentication. So, how do we prevent these types of attacks?
To avoid broken authentication vulnerabilities, we need to make sure that the developers apply the best practices of web application security. Developers should have enough time to properly test the code before deploying to production.
OWASP recommends the following techniques to prevent broken authentication vulnerabilities:
Enable Multi-Factor Authentication
Multi-Factor Authentication (MFA) is a security system that requires more than one method of authentication from independent categories of credentials to verify the user’s identity for a login or other transaction. MFA combines two or more independent credentials from:
- What the user knows (His credentials)
- Something that the user possesses (Security tokens received via SMS/authenticator app)
- What the user is (Biometric verification)
Wherever possible, we should implement multi-factor authentication to prevent automated credential stuffing, brute force, and stolen sessions reuse attacks.
We have explained how to implement Multi-Factor Authentication in our article Two-Step Verification with ASP.NET Core Identity. Authenticator apps that use a Time-based One-time Password Algorithm (TOTP) are the industry recommended approach and are preferred to SMS based MFA. How to use TOTP using an authenticator app is explained in detail in Enable QR Code generation for TOTP authenticator apps in ASP.NET Core.
Prevent Weak & Default Passwords
Our application should not allow users to create weak passwords. While a user is setting a password, we should enforce password rules and check for weak passwords. We should align password length, complexity and rotation policies by following NIST 800-63 B’s guidelines section 5.1.1 for memorized secrets or other modern, evidence-based password policies.
It is also a good practice to check against a list of known worst passwords that are available online. This is described in the List of the most common passwords. And also HaveIBeenPwned.
Similarly, we should never ship or deploy our application with any default credentials, particularly for admin users.
Implement Strong Credential Recovery Process
User registration and credential recovery are the key areas which the attackers target to perform User Enumeration Attacks. User Enumeration Attack is the process of checking a list of usernames against an application to check for the valid ones. If our application returns different messages or URLs for different cases such as when username does not exist when username exists but the password is wrong etc, it becomes vulnerable to Account Enumeration Attacks.
To protect our application against these types of attacks, we should ensure that user registration, credential recovery, and API pathways are hardened against Account Enumeration Attacks by using the same messages for all outcomes.
ASP.NET Core Identity helps us to implement these features using industry-standard best practices. We have explained how to implement user registration, email confirmation and password reset using ASP.NET Core Identity in our linked articles.
Limit/Delay Successive Failed Login Attempts
A common threat web developers face is password-guessing attack also known as Brute-Force Attack. It is an attempt to discover a password by systematically trying every possible combination of letters, numbers, and symbols until they discover a correct combination that works.
An attacker can always discover a password through a brute-force attack, but it could take years to find it. Depending on the password’s length and complexity, there could be trillions of possible combinations. To speed things up a bit, a brute-force attack could start with dictionary words or slightly modified dictionary words because most people will use those rather than a completely random password. These types of attacks put our user accounts at risk and flood our website with unnecessary traffic.
Let’s see how we can prevent these types of attacks:
Account Lockout
Although such attacks are easy to detect, they are not so easy to prevent. The most obvious way to block brute-force attacks is to simply lock out accounts after a defined number of incorrect password attempts. Account lockouts can last a specific duration, such as one hour, or the accounts could remain locked until manually unlocked by an administrator. We may also consider locking out authentication attempts from known and unknown browsers or devices separately.
We have explained the user account lockout functionality in detail in our article User Lockout with ASP.NET Core Identity.
CAPTCHA
CAPTCHA is a program that allows us to distinguish between humans and computers. They are particularly effective in stopping most kinds of automated abuse including brute-force attacks. They work by presenting some tests that are easy for humans to pass but difficult for computers to pass. Therefore, they can conclude with some certainty whether there is a human on the other end. We may also present a CAPTCHA to a user on successive failed login attempts.
Logging
Last but very important, we should always log all failures and alert administrators when credential stuffing, brute force, or other types of attacks are detected. We have explained how to do logging in ASP.NET Core application in the article: ASP.NET Web API – Logging With NLog.
Use Best Practices for Session Management
We should always use a server-side, secure session manager that generates a random and unpredictable session ID every time. Similarly, we should also make sure that the session IDs are never revealed through URLs. We should store Session IDs securely and invalidate it after logout, idle and absolute timeouts.
ASP.NET Core Identity is a good framework that handles session management using industry-standard best practices. We have covered how to implement the complete authentication workflow using ASP.NET Core Identity in detail in our series – ASP.NET Core Identity Series.
Conclusion
In this article, we have explained about broken authentication, which is the second most critical vulnerability as per OWASP top 10 lists.
We have covered the following topics in the article:
- How a web application can become vulnerable to broken authentication attacks.
- A few example attack scenarios.
- How we can prevent the broken authentication attacks.
In the next part of this series, we will discuss sensitive data exposure.
