The Ultimate Guide for Broken Authentication

Broken authentication is a security vulnerability that occurs when an application fails to properly authenticate its users. This can lead to unauthorized access to sensitive information, data breaches, and other security issues.

Broken authentication is a threat that has to be taken seriously and it has a significant impact on Web Application Security. 

We talked about Broken Access Control in the previous post in this blog series. In this ultimate guide, we will take a deep dive into what broken authentication is, how it can be exploited, and most importantly, how to prevent it. We will cover the best practices and techniques that will help you secure your applications and protect your users’ data.

Before getting into this topic, you’d better take a look at these articles written by the PurpleBox Team to learn more about OWASP and OWASP Top 10 Security Vulnerabilities:

• An Introduction to Application Security
• What is OWASP?
• A Closer Look at OWASP Top 10 Security Risks & Vulnerabilities
• A Comprehensive Guide to Broken Access Control

1. What is Broken Authentication?

According to OWASP, Authentication is the process of verifying that an individual, an entity, or a website is who it claims to be. Authentication in the context of web applications is commonly performed by submitting a username or ID and one or more items of private information that only a given user should know.

1.1 Authentication Factors

Authentication factors can be classified into different groups such as something you know, you have, you are or you do.

1.2 Reasons Behind Authentication Vulnerabilities

Authentication mechanisms rely on a variety of technologies to verify one or more of the factors we have discussed. Improper configuration and poor implementation of authentication mechanisms can lead to authentication vulnerabilities.

There are mostly two reasons behind the authentication vulnerabilities:

1. Insufficient protection against brute-force attacks and missing rate-limit make the authentication mechanism weak.
2. Poor coding and logic errors in the authentication mechanism allow attackers to bypass the entire authentication process. This is exactly what “Broken Authentication” is.

Authentication is not only the process of verifying the identity of a given user or client in a single phase, but it is also a confirmation of the users and clients who were claimed to be.

2. Real-World Examples

2.1. Username Enumeration

Web applications do not let you in when invalid credentials are entered. While some applications throw a message like “Invalid username or password!”, some of them indicate whether the username is valid. This leads to username enumeration and makes the attack surface wider for attackers.

While the first application handles the case in a security-oriented way, the second one allows attackers to enumerate users.

Sometimes, applications do not throw obvious messages, but they give subtly different responses. A typo, size page, or response time might be signs of vulnerability.

On the login page;

Incorrect response examples:

• “Login for User foo: invalid password.”
• “Login failed, the invalid user ID.”
• “Login failed; account disabled.”
• “Login failed; this user is not active.”

Correct response examples:

• “Login failed; Invalid user ID or password.“
• “Login failed; Invalid username or password.“

2.2. Lack of Brute Force Protection

Web applications suffering from insufficient brute-force protection are much more vulnerable to attacks that target authentication mechanisms.

For instance; if an application is vulnerable to username enumeration as shown in the previous page, then an attacker could easily perform a brute-force attack to find usernames very quickly. Furthermore, the attacker can succeed in finding the password of the victim in a very short time frame via a brute-force attack again.

2.3 Password Reset Poisoning via Header Injection

Since “forgot password” functions are directly related to authentication, user accounts could easily be compromised in this way. Not only can attackers take over user accounts, but they can also get access to administrator accounts.

The illustration below shows the exploitation of a well-known authentication vulnerability through the password reset function. In that scenario, the attacker manages to fetch the password reset token of a normal user by carrying out a “host header injection” attack.

Steps to reproduce the attack above:

1. The attacker requests a password reset mail on behalf of Carlos.
2. The attacker intercepts the request and injects a Host header with his malicious server address.
3. Since the web application trusts the Host header, the password reset link points to the attacker’s server.
4. When Carlos clicks that link, the password reset token will be obtained by the attacker.

2.4 Use of Non-Standard Authentication Protocol

Although authentication through a user/password combination is usually accepted as secure, there are some use cases where it isn’t considered the best option or even safe. Third-party applications that desire to connect to the web application -either from a mobile device, another website, desktop, or other situations- are good examples for this case.

Here, the critical point is that allowing the third-party application to store the user/password combo is not considered safe as it extends the attack surface where you have no control.

2.5 Mass Assignment (Object Injection)

An application has a login function and two levels of privileges:

1. User
2. Admin

Suppose there is an HTML form for editing a user’s account information:

Here is the object that the form is binding to:

Here is the controller handling the request:

A normal user sends the request below to authenticate:

The application authenticates the user with user privileges.

To discover and exploit the vulnerability, a malicious user needs to manipulate the request above. Therefore, the user can intercept and change the request via a proxy tool to perform the attack.

The application authenticates the user with admin privileges. Consequently, the mass assignment vulnerability in the web application led to an application-level privilege escalation.

2.6 Pre-Account Takeover

An attacker can take over an unregistered user account via the methods following.

Method #1:

1. Go to the target website and sign up using the unregistered victim’s account.
2. The application may or may not ask for email verification.
3. After a while, the victim signs up using no password methods/protocols.
4. Now the attacker can easily log into the victim’s account and consequently, the email verification is bypassed. Moreover, the attacker is still able to log into the victim’s account with the same password he had created.

Method #2

1. Go to the target website and sign up using a no-password method.
2. Change your email address to the victim’s email address.
3. After a while, the victim tries to sign-up using email registration and the application responds with a “User already exists!” message.
4. The victim requests a password reset mail and changes his password.
5. Now, the attacker can still log into the victim’s account using no password methods.

2.7 Non-Destructed Password Reset Link After Email Change

An attacker can take over a user account if password reset links are not destroyed after an email change.

1. Assume that you have an account on example.com, and request a password reset link.
2. Do not use the link and sign in to your account.
3. Change your email address.
4. Go back to your inbox and change your password by using the reset link you requested in Step 1.
5. See that you can change your password via a password reset link linked to your old email address which you no longer use.

2.8 Signing Up As Administrator

Assume that the target application takes usernames from users while registering and usernames are case-sensitive.

1. Navigate the registration page and try to register with the username “admin”.
2. If you get a message like “User already exists!”, then try signing up with username “Admin” or “AdmiN”, etc.
3. Observe that you likely have now admin privileges.

3. Remediation Guidelines

3.1 User IDs / Usernames

• Email Address as User ID: Make sure usernames and user IDs are case-insensitive. Your application must not allow registering with usernames ‘john’ and ‘John’ separately. User ‘john’ and ‘John’ should be the same user. Usernames should also be unique.
• Input Validation / Email Validation: Implement a proper validation and verification mechanism for inputs and emails.

3.2 Authentication Solution and Sensitive Accounts

• Do NOT let sensitive accounts (DB, back-end, any internal account…) authenticate to front-end user interfaces.
• Do NOT use the same authentication solution (e.g. IDP / AD) used internally for unsecured access (e.g. public access / DMZ)

3.3 Proper Password Strength Controls (Policy)

In password-based authentication systems, password strength is the key concern.

• Password Length: A “strong” password policy makes it difficult or even improbable for attackers to guess the password through either manual or automated means.
• Allow All Characters: Allow usage of all characters including Unicode and whitespace. There should be no password composition rules limiting the type of characters permitted.
• Credential Rotation: Ensure credential rotation when a password leaks, or at the time of compromise identification.
• Password Strength Meter – Breached Passwords: Include a password strength meter to help users create a more complex password and block common and previously breached passwords

3.4 Secure Password Recovery Mechanism

• To prevent user enumeration, throw consistent messages.
• In case of too many failed login attempts, lockout accounts and prevent DoS attacks.
• Increase token safety and entropy.
• Requiring re-login after a password reset.
• Invalidate previously created sessions after a password reset.
• Inform users via email when the password is changed.

3.5 Re-Authentication for Sensitive Functions

Re-authentication for sensitive functions plays a key role in mitigating CSRF attacks.

3.6 Strong Transaction Authentication

TLS Client Authentication, also known as two-way TLS authentication, consists of both, browser and server, sending their respective TLS certificates during the TLS handshake process. Just as you can validate the authenticity of a server by using the certificate and asking a well-known Certificate Authority (CA) if the certificate is valid, the server can authenticate the user by receiving a certificate from the client and validating against a third-party CA or its own CA.

3.7 Authentication and Error Messages

Incorrectly implemented error messages in authentication functionalities can be used for user ID and password enumeration. An application should respond (both HTTP and HTML) in a generic manner. Furthermore, over-verbose error messages can help attackers to identify the weak points and infrastructure of the application.

3.8 Protection Against Automated Attacks

Brute Force: Testing multiple passwords from a dictionary or other source against a single account

Credential Stuffing: Testing username/password pairs obtained from the breach of another site

Password Spraying: Testing a single weak password against a large number of different accounts

Different protection mechanisms can be implemented to protect against these attacks. These defenses do not always provide full protection. However, implementing several defenses in a defense-in-depth approach can provide a reasonable level of protection. 

3.8.1 Multi-Factor Authentication (MFA)

Multi-factor authentication (MFA) is by far the best defense against the majority of password-related attacks, including brute-force attacks.

3.8.2 Account Lockout

The key elements in the account lockout mechanism are

• Lockout Threshold: The number of failed attempts before the account is locked out.
• Observation Window: The period that these attempts must occur within.
• Lockout Duration: For how long the account is locked out.

3.8.3 CAPTCHA

The use of an effective CAPTCHA can help to prevent automated login attempts against accounts. It may be more user-friendly to only require a CAPTCHA to be solved after a small number of failed login attempts, rather than requiring it from the very first login.

3.8.4 Logging & Monitoring

All failures including all failed login attempts and account lockouts must be logged and monitored in real-time to detect any attack intentions.

3.8.5 Use Standard Authentication & Authorization Protocols

Use standard authentication protocols that can protect you from exposing your users’ data to attackers.

• Open Authorization (OAuth)
• OpenID
• Security Assertion Markup Language (SAML)
• The Fast Identity Online (FIDO) Alliance

3.8.6 Session Management

To implement a proper and secure session management system, attributes of session identifiers must be designed carefully.

The session ID or token binds the user authentication credentials to the user HTTP traffic and the appropriate access controls enforced by the web application.

Session ID Properties:

• Session ID Name Fingerprinting: The name used by the session ID should not be extremely descriptive nor offer unnecessary details about the purpose and meaning of the ID.
• Session ID Length: The session ID must be long enough to prevent brute force attacks, where an attacker can go through the whole range of ID values and verify the existence of valid sessions. The session ID length must be at least 128 bits (16 bytes).
• Session ID Entropy: The session ID must be unpredictable (random enough) to prevent guessing attacks, where an attacker can guess or predict the ID of a valid session through statistical analysis techniques. For this purpose, a good CSPRNG (Cryptographically Secure Pseudorandom Number Generator) must be used.
• Session ID Content (or Value): The session ID value should be meaningless to prevent information disclosure attacks, where an attacker can decode the ID and extract user, session, or application details. The session ID must simply be an identifier on the client side, and its value must never include sensitive information (or PII).

5. Conclusion

In the A Comprehensive Guide to Broken Access Control blog post, authorization was discussed comprehensively. In this blog post, we have provided detailed information about authentication and a deeper understanding of related attack vectors and security risks.

In conclusion, broken authentication can have severe consequences for individuals and organizations alike. By following best practices for authentication, such as using strong passwords, multi-factor authentication, and regularly updating software, we can help prevent these types of attacks. It is also important to remember that authentication is just one aspect of overall security, and a comprehensive approach to security is necessary to protect against all types of threats.

Check out our Vulnerability Management and Penetration Testing services to stay secure!