Identification and authentication failures

January 20, 2025 Celia Catalán

Identification, authentication, or authorization?

First, we must understand the difference between identification and authentication:

ID: It is the process where an identity is provided; a user or system indicates who they are.
Authentication: It is the process of verifying an identity. When a user or system identifies itself, it indicates who it is; when it authenticates, it is checked that it is who it claims to be.

Although most of the well-known failures are related to authentication, as this is where security checks are performed to verify the identity of users, there are also failures in the identification process that can affect information security. Some examples are:

Incorrect or unrecognized identification: If a user enters an unregistered username or ID in the system, the identification process fails because no identity is associated with that entry.

Duplicate identity: In some systems, there may be two accounts with similar usernames or very similar IDs, which creates confusion when trying to associate which user the identification refers to.

On the other hand, it is crucial to understand the difference between authentication and authorization, which, although they sound similar, are distinct processes. While authentication, as we have explained, verifies the identity of a user or system, authorization determines whether that user or system has permission to perform or access a specific action or resource.

Authentication factors

There are three main types of authentication factors, based on simple principles: something the user knows, something the user has, and something the user is.

Something that the user knows: for example, a password or the answer to a security question.

Something that the user has: like a physical object or a security token.

Something that the user is: as a biometric data (fingerprint) or behavioral patterns.

Although passwords remain the most common authentication mechanism, each system may require different types of factors to verify the user's identity. Nowadays, there are multiple mechanisms: from those based solely on biometric data (such as smartphone unlocking) to those that use specific hardware (such as removable devices). Additionally, the use of multifactor authentication is becoming increasingly common, combining, for example, passwords with security tokens.

This diverse landscape of authentication mechanisms offers greater flexibility and enhances the overall security of systems. However, it also introduces new complexities and potential weak points that attackers could exploit.

Next, we will analyze the different types of vulnerabilities related to the authentication process, grouping them according to the affected mechanism. We will focus on these vulnerabilities as they represent the majority of security failures in this area.

Password-based authentication

Systems that use only username and password as an authentication method rely entirely on the password as proof of the user's identity. This implies that an attacker who obtains a user's credentials could completely compromise the authentication process. There are various types of attacks to exploit this mechanism:

Brute force

Brute force attacks are a trial and error process where the attacker constantly inputs different credentials —randomly, following rules, or using word dictionaries— in order to discover the credentials of a legitimate user.

Before attempting to discover the password, if no username is known, it is necessary to perform a user enumeration. There are several methods to identify valid usernames in a web application.

The first one is based on the server's response. When entering a registered user in the application, we receive a different response than when entering a non-existent user. To automate this process, we can use tools like BurpSuite's Intruder, which allows for brute force attacks on parameters in a web request using word dictionaries or rules to generate sequences of characters and numbers. In the following example, we observe that one of the entered words returns a response of a different size than the others:

"We verified in the response to this request that the platform indicates that the password is not valid, unlike the other responses that state that the user entered is not valid:"

"It's not always something so obvious; sometimes we need to look for subtle flaws in the program itself. In the following case, we observe a similar situation. Although all the responses are of different sizes and indicate that the username or password is invalid, there is a small spelling mistake in the programming of the response. This error causes a slight variation in the response when entering an existing username:"

Correct answer:

Incorrect answer:

Another method, when the response is always the same, is to use the response time as an indicator. If we enter a very long password, and the server only processes it when the user is correct, it may take longer to try to process such a long string of characters. In this example, we test with different users always using a very long password:

There are many more user enumeration techniques. If you are interested in learning about them, you can visit our post on the "Insecure Design" vulnerability from OWASP.

IP block evasion

"It is possible to encounter login restrictions. The most common block is the IP block, where the server temporarily blocks login attempts from a specific IP address. However, there are methods to bypass this block. For example, the use of headers like X-Forwarded-For, which, if processed by the server, can lead to an evasion of the IP block."

In other cases, the blocking may occur after a certain number of attempts, but it resets once a user logs in successfully. For example, if we detect that the IP is blocked after 3 attempts, we can use a credential dictionary and intersperse the credentials of a legitimate user (we need to have the credentials of some user) every 2 entries of the dictionary. With this method, we can avoid the blocking and test all the entries of our dictionary.

There are also cases where the enumeration or evasion of the authentication scheme can be done with a single HTTP request, thus bypassing any blocking due to repeated login attempts. For example, when sending a JSON to log in, if we send an array of passwords instead of a single value, the server could correctly process this JSON and allow us to log in without knowing the correct user credentials.

User account block evasion

Account locking is another security mechanism. Unlike IP blocking, this method locks the account after multiple failed login attempts. However, if the system only locks existing accounts, this can inadvertently lead to user enumeration. For example, by repeatedly trying to log in with different usernames, we notice that a particular account gets locked after the fifth failed attempt:

In this way, we achieve a user enumeration in the web application's login panel.

Basic Access Authentication

Although this method is very old, it is still possible to find servers that use this vulnerable system. This authentication mechanism consists of concatenating the username and password, encoding them in Base64, and inserting them into the Authorization header in each request:

This method is particularly dangerous. Unless the website implements HSTS, an attacker performing a man-in-the-middle attack could intercept this header. By simply decoding it, they would obtain the user's credentials.

Multi-factor authentication

"Authentication methods based solely on passwords place all security in a single parameter: something that the user knows."

In contrast, multifactor authentication introduces at least one additional factor. A common example is two-factor authentication (2FA), which requires something the user knows (a password) and something they have (like a one-time code sent via email). However, there are other combinations, such as the use of fingerprints —something that the user is— or authentication apps like Microsoft Authenticator, a mobile app that replaces the code sent by email.

Bypassing two-factor authentication

The simplest case occurs when the system considers the user authenticated after entering only the first factor, despite requesting a second. For example, if we know a user's password and have information about directories or resources reserved for authenticated users, we could access these directly without providing the requested security token. This highlights a poor implementation of the second authentication factor, as the system should only consider users authenticated who have completed the entire process.

Lateral movement due to implementation failure

"Similar to the previous case, here we observe a problem in verifying that all steps of the process have been completed by the user attempting to access. Although it may seem confusing, the following example illustrates it clearly."

Let's consider a web application with two-factor authentication (2FA). After entering the username and password, the application requests a security token to confirm the identity. A GET request is made to /login2 for the server to send the token to the user's email. The server sends this token to the user specified in the Cookie header of the request:

In this way, if we replace our username with that of the victim, the server will send the access token to the victim user's email:

Once this token arrives in the victim's email, the attacker can begin the login process with their own user credentials and proceed to enter the token. When entering the token, if they change this Cookie header again to input the victim's username and perform a brute force attack on the security token, they will be able to discover the security token sent to the email and access the victim's account with it:

In this case, the server only verifies the second step of the authentication process, that is, the security token. If the token is valid and matches the one sent to the user specified in the Cookie header, the server grants access. However, it does not validate that the credentials provided in the first step of authentication (such as the username and password) correspond to the user being attempted to access.

Vulnerabilities in other authentication mechanisms

The vulnerabilities associated with the authentication process are not limited solely to the login. They can also be found in other critical procedures, such as password changes, updating the email address, or managing session persistence, as we will see below.

"Keep me signed in" option

On many websites, when logging in, there is an option to keep the session active even if we close and reopen the browser. This functionality is implemented through a persistent cookie, similar to a session cookie, but with a longer duration (at least for a specified period). Although this practice is very common, the security of the application may be compromised depending on how this token is designed and managed.

In the following example, by selecting the option to keep the session logged in and log in, we observe the presence of the following cookies:

The first cookie corresponds to the active session, while the second is the persistent cookie mentioned earlier. This token should only be accessible to the user who has logged in. However, upon analyzing it, we have observed that it is relatively predictable, as it is encoded in Base64 and contains the username followed by the MD5 hash of their password:

Knowing the structure of the token, it is possible to attempt a brute force attack to generate a valid token and access the user's account. To do this, we will use Intruder from BurpSuite to perform a fuzzing of the parameter corresponding to the persistent cookie. The first step will be to convert all the passwords into their respective MD5 hashes:

Once the MD5 hash list is created, we will use it as a dictionary for our attack. However, before that, it is necessary to perform a post-processing of the dictionary: we will add the victim's username as a prefix followed by :, and then convert the entire string to Base64. Subsequently, we execute the attack with Intruder, which will allow us to obtain a successful response by accessing the victim's profile using one of the generated persistent cookies.

Cookie theft via XSS

It is possible that the server will block us if we make too many requests while testing different tokens, but there are other methods to bypass this restriction. Instead of testing multiple cookies, we could try to steal the session cookie of a user. If the token follows a scheme like user:hash[password], as in the previous case, we can try to crack the hash using brute force with tools like hashcat. But how can we obtain a user's cookie? This can be achieved through an XSS attack, as detailed in the following example.

The comments section of one of the blogs turns out to be vulnerable to a JavaScript code injection. This page is accessible to other users, so by injecting malicious code, our victim could access the comments section and execute the JavaScript code without realizing it. To steal the session cookie, we first set up a server that waits to receive requests, and then we inject the following code into the comments:

In this way, the victim, when trying to load that object i, will make a request to our server by inserting their session cookies into that request. Immediately afterwards, we will receive this information on our server, as we can see in the following image:

We observe again that this is a Base64 encoded string in the following format:

"As the server blocks us when making too many requests, we can try to crack this hash using hashcat with a dictionary like rockyou.txt:"

As we can see in the image, we managed to crack the hash and obtain the victim's password.

Error in password change

It is possible to identify flaws in the logic of the password change process, especially when a user forgets their password and requests a change via email. In this case, a link is sent to the email associated with the user who has forgotten their password, allowing them to change it to a new one. However, the request made by clicking on the link includes the following parameters in the body:

As we can see, there is a parameter indicating the user, and this is modifiable by the user. If instead of our user, we write the victim's username, we can change the victim's password without knowing their current password:

Password change poisoning

To understand this vulnerability, it is essential to first explain how the password change process works. Generally, when a user forgets their password, the server sends a link to the associated email that redirects to a page to reset it. Since the user cannot access their account, they cannot use a session token to verify their identity. For this reason, the server often generates a one-time token and embeds this token in the redirect link to the password change page. The security of this token relies on the fact that only the user who has access to their email can access the link and, therefore, the token, and that once used, the token loses its validity.

However, there is a vulnerability that can compromise this system. When creating the password reset link, the server must include both the host and the token parameter in the URL:

The host should always be the same, corresponding to the legitimate website. However, in certain cases, the server determines the host of the URL based on the value of the Host header of the request made when the client clicks "send email", and this header can be manipulated by an attacker. In this way, a malicious actor can trick the server into sending an email with a malicious link to the victim.

To carry out this attack, the attacker must click on the "forgot password" button and enter the victim's username instead of their own. Then, using a proxy tool like BurpSuite, they intercept the request and modify the Host header, replacing the server's host with the URL of a server that is under their control:

In this way, the server will send the victim an email with a link to change the password, including a temporary token. However, the host of that link will belong to the attacker. If the victim clicks on this link, it will send a request to the attacker's server, which will intercept the request and capture the temporary token. In this way, the attacker will be able to change the victim's password and take over their user account.

"It is possible to find servers that support non-standard headers and, in this context, instead of using the Host header to generate the link, the server could use headers like X-Forwarded-Host:"

How to prevent authentication attacks

Protecting authentication mechanisms is essential to avoid vulnerabilities that could compromise a website and user data. Below are the most significant measures:

Beware of credentials: Never send login data over unencrypted connections. Implement HTTPS and automatically redirect HTTP requests. Audit the site to prevent exposure of usernames or emails.
Not relying on users: Users often avoid strict security policies. Instead of applying traditional password policies, it is more effective to use password checkers, such as the zxcvbn library, which provide real-time feedback on password strength.
Prevent username enumeration: Avoid giving hints about whether a user exists in the system through generic error messages, with identical response times and HTTP codes.
Protection against brute force attacks: Implement limits on the number of login attempts per IP address and use CAPTCHA after several failed attempts. This makes it difficult for attackers to efficiently carry out brute force attacks.
Logic Verification: Thoroughly audit the authentication logic to ensure there are no flaws or potential bypasses that could be exploited.
Attention to additional functionalities: Functions such as password resets are also vulnerable, so they must be as secure as the main login.
Multi-factor authentication (2FA): Implementing 2FA using dedicated apps or devices is more secure than methods like sending codes via SMS or email. Audit the 2FA logic to prevent it from being bypassed.