For this section, I will be using the information provided from the OWASP website which can be viewed here.
To understand what broken authentication it is better to first understand what the potential threat agents and attack vectors are.
“Attackers have access to hundreds of millions of valid username and password combinations for credential stuffing, default administrative account lists, automated brute force, and dictionary attack tools. Session management attacks are well understood, particularly in relation to unexpired session tokens.”
From this information, we can see that broken authentication is anything regarding getting into or information regarding other users’ accounts, including administrative accounts. Further on we read about the security weakness.
“The prevalence of broken authentication is widespread due to the design and implementation of most identity and access controls. Session management is the bedrock of authentication and access controls, and is present in all stateful applications. Attackers can detect broken authentication using manual means and exploit them using automated tools with password lists and dictionary attacks.”
So when really looking at broken authentication, we can see that it is much more than just broken access controls. Broken authentication reaches a much broader range but can be tied into broken access controls. We can see this by looking at how an application is vulnerable to this vulnerability.
Confirmation of the user’s identity, authentication, and session management are critical to protect against authentication-related attacks. There may be authentication weaknesses if the application:
- Permits automated attacks such as credential stuffing, where the attacker has a list of valid usernames and passwords.
- Permits brute force or other automated attacks.
- Permits default, weak, or well-known passwords, such as “Password1” or “admin/admin“.
- Uses weak or ineffective credential recovery and forgot-password processes, such as “knowledge-based answers”, which cannot be made safe.
- Uses plain text, encrypted, or weakly hashed passwords (see A3:2017-Sensitive Data Exposure).
- Has missing or ineffective multi-factor authentication.
- Exposes Session IDs in the URL (e.g., URL rewriting).
- Does not rotate Session IDs after successful login.
- Does not properly invalidate Session IDs. User sessions or authentication tokens (particularly single sign-on (SSO) tokens) aren’t properly invalidated during logout or a period of inactivity.
As you can see from the above list, there are many factors that lead to broken authentication. Technically speaking, if we look at this vulnerability reported by Clayton regarding the use of xmlrpc.php file within WordPress. We can see that this file can be used for an amplification brute force attack, which would technically classify this vulnerability as Broken Authentication because it meets the criteria for an application to be vulnerable as described from OWASP.
If we look at the scenarios provided by OWASP, we can see what I user can do to protect themselves from this vulnerability.
Example Attack Scenarios
Scenario #1: Credential stuffing, the use of lists of known passwords, is a common attack. If an application does not implement automated threat or credential stuffing protections, the application can be used as a password oracle to determine if the credentials are valid.
Scenario #2: Most authentication attacks occur due to the continued use of passwords as a sole factor. Once considered best practices, password rotation and complexity requirements are viewed as encouraging users to use, and reuse, weak passwords. Organizations are recommended to stop these practices per NIST 800-63 and use multi-factor authentication.
Scenario #3: Application session timeouts aren’t set properly. A user uses a public computer to access an application. Instead of selecting “logout” the user simply closes the browser tab and walks away. An attacker uses the same browser an hour later, and the user is still authenticated.
These scenarios provide an excellent example of what the scenarios can be so to break it down simply, to protect yourself from a broken authentication vulnerability there are a few key things to follow.
- Never Reuse a password that is used elsewhere, if one of the account’s passwords is leaked, an attacker can add it to a wordlist to be able to get into your other account.
- Implement the use of randomly generated passwords to make it much harder for an attacker to be able to get access to your account. The use of a password manager such as Bitwarden or Lastpass can make this easier than ever.
- Whenever possible, enabling two-factor authentication can be a highly effective way of mitigating an attacker from fully login into an application.
- When using a public device, or one that is not your own, always make sure that your account is fully logged out before closing the application to prevent the next user from gaining access to your account.
So now we know how to protect ourselves from an attacker utilizing this vulnerability against our individual accounts, but what can an application do to prevent these attacks? Luckily OWASP provides this to us as well.
- Where possible, implement multi-factor authentication to prevent automated, credential stuffing, brute force, and stolen credential re-use attacks.
- Do not ship or deploy with any default credentials, particularly for admin users.
- Implement weak-password checks, such as testing new or changed passwords against a list of the top 10000 worst passwords.
- Align password length, complexity and rotation policies with NIST 800-63 B’s guidelines in section 5.1.1 for Memorized Secrets or other modern, evidence based password policies.
- Ensure registration, credential recovery, and API pathways are hardened against account enumeration attacks by using the same messages for all outcomes.
- Limit or increasingly delay failed login attempts. Log all failures and alert administrators when credential stuffing, brute force, or other attacks are detected.
- Use a server-side, secure, built-in session manager that generates a new random session ID with high entropy after login. Session IDs should not be in the URL, be securely stored and invalidated after logout, idle, and absolute timeouts.
This is clearly a huge problem as we can see that OWASP labeled this as the second most common vulnerability, and I think a large part of that is due to the fact that this vulnerability relies on not only the application and its developers implementing the correct features, but also the proper handling of safe account management on the individual user’s account. The biggest way to mitigate this is to inform users of risks, and how to stay safe.