The Ultimate Guide for Broken Authentication

December 08, 2021



1. Introduction

While sometimes mistakenly used interchangeably, authentication and authorization represent fundamentally different functions. In simple terms, authentication is the process of verifying who a user is, while authorization is the process of verifying what they have access to. 

We can begin comparing authentication and authorization by asking who you are and what you are allowed to do. Let’s have a look at the figure below:

Authentication is the process of verifying who a user is, while authorization is the process of verifying what they have access to.

If we compare these processes to a real-world example, you can think of going through security in an airport and showing your ID to authenticate your identity. Then, when you arrive at the gate, you present your boarding pass to the flight attendant, so they can authorize you to board your flight and allow access to the plane.

We have talked about Broken Access Control in the previous post in this blog series. In this blog post, we will introduce Broken Authentication.

Broken Authentication is a threat that has to be taken seriously and it has a significant impact on Web Application Security. 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:

2. 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.

2.1 Authentication Factors

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

The image shows authentication factors and some examples.

2.2 Reasons Behind Authentication Vulnerabilities

Authentication mechanisms rely on a range of technologies to verify one or more of the factors that we have talked about. Improper configuration and poor implementation of authentication mechanisms cause authentication vulnerabilities to arise. 

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 are who were claimed to be.

In the figure, attacker Bob changes the hidden field’s value to the victim’s ID and authenticates it as the victim.

3. Real-World Examples

3.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.

This image highlights the importance of consistent error messages to prevent username enumeration.

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 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.“

3.2. Lack of Brute Force Protection

Web applications suffering from insufficient brute-force protection are much more vulnerable to the attacks which 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.

3.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.

The figure demonstrates a host header poisoning 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.

3.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.

3.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:

Mass Assignment 1

Here is the object that the form is binding to:

The back-end object that the form above binds to.

Here is the controller handling the request:

The back-end code handles the requests.

A normal user sends the request below to authenticate:

The figure shows the original POST request for adding a user.

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.

This figure shows the modified POST request that results in Mass Assignment.

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

3.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 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.

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.

3.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.

4. Remediation Guidelines

4.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 username ‘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.

4.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)

4.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

4.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.

4.5 Re-Authentication for Sensitive Functions

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

4.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.

4.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.

4.8 Protection Against Automated Attacks

The most common brute force attacks are Brute-Force, Credential Stuffing and Password Spraying.

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. In many cases, these defenses do not provide complete protection, but when a number of them are implemented in a defense-in-depth approach, a reasonable level of protection can be achieved.

4.8.1 Multi-Factor Authentication (MFA)

The figure shows different types of multi-factor authentication: Knowledge – Possession - Inherence

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

4.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: How long the account is locked out for.

4.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.

Some CAPTCHA practices to ensure user interaction.

4.8.4 Logging & Monitoring

The figure above illustrates logging and monitoring the activities.

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

4.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 

4.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. 

This image shows us the relation between authentication, session management, and access control.

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 content (or value) must be meaningless to prevent information disclosure attacks, where an attacker can decode the contents of the ID and extract details of the user, the session, or the inner workings of the web application. 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 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.

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