Authentication and, by extension, user identification are central to web applications.
These two mechanisms are used to manage rights and access (for example, between an administrator and a standard user), to partition data between different accounts, to identify different users, etc.
In short, authentication is crucial and its compromise can have a critical impact on the application: account theft, data theft, imitation of a third-party account, or even total compromise of the platform in the event of theft of an administrator account.
In this article, we explore the vulnerabilities associated with identification and authentication failures through the prism of OWASP. Using attack scenarios as a starting point, we will detail common exploits and best practices to protect against them.
What are the most common authentication methods?
The aim of an authentication system is to identify a user and ensure that he is who he claims to be. In fact, all authentication systems rely on at least one of these 4 factors:
- What we know (knowledge factor): information that only the user knows, such as a password.
- A physical factor: an object that is only in the user’s possession, e.g. an access card.
- A biological factor, such as a fingerprint.
- Or what we know how to do (a “singular” factor), an action that only the user knows how to do, for example a signature.
Each of these systems has advantages and disadvantages, but only the first 3 criteria are reasonably used today in IT to identify a user, and of these 3, the first dominates massively with the famous “user name – password” combination. So we’re going to focus on this one.
More recently, this combination has been reinforced by 2FA (Two-factor authentication). This type of mechanism requires, in addition to the password, a code received via a second channel, usually by email or telephone. This ensures that even if the password is compromised, a malicious actor cannot connect to the platform.
Unfortunately, no authentication system is foolproof. Implementation or configuration problems can allow an attacker to bypass and/or abuse it.
In this article, we will not explain all the possible attacks on authentication. We will focus on the most common ones.
What are the common attacks and exploits on authentication systems?
Brute force attacks on authentication factors
The most obvious and best-known case: trying out different passwords until you find the right one using brute force. It can also be used to bypass certain types of 2FA, for example if a 4- or 5-digit code is requested.
The most obvious and best-known case: trying out different passwords until you find the right one using brute force. It can also be used to bypass certain types of 2FA, for example if a 4- or 5-digit code is requested.
This attack is easy to detect and counter. All you need to do is set up a rate limiting system or implement a delay between each connection attempt.
Another protective measure is to introduce a strong password policy.
To find out more about brute force attacks, please see our dedicated article: Brute force attacks: security principles and best practices.
Password Reset Vulnerabilities
A recurring feature in authentication systems is the password reset feature.
It generally works like this:
- The user enters their username (usually an email address).
- An email containing a reset link is sent to the user.
- Following this link, the user is redirected to a form where he/she can enter a new password.
A vulnerability often identified during this process is the generation of the link itself. An attacker who has access to this link can change the password of an account that does not belong to him, and thus steal the account.
Example of exploitation
Take, for example, the following link, received when we attempted to reset the password of the user “[email protected]” on a test site:
https://test.vaadata.com/passwordreset/ZHVtbXkxQHRlc3QtdmFhZGF0YS5mcg==It seems that : ZHVtbXkxQHRlc3QtdmFhZGF0YS5mcg== is the part that identifies the account to which the password reset applies.
When we make a second reset request with the same email, something interesting happens:
We get the same URL, which is a bad sign because it means that the code is not randomly generated.
If we try to decode the id in base64, we get: “[email protected]”.
Given the behaviour observed, it would appear that the password reset is based solely on the base64-encoded email to identify the account making the request. By replacing this id with that of an account that we do not own, we should be able to steal that account.
Let’s try with “[email protected]”, which becomes ZHVtbXkyQHRlc3QtdmFhZGF0YS5mcg== in base64.
Bingo! With this, we can steal any account, as long as we know its email address.
How to prevent this type of exploitation?
To protect against this type of attack, the reset token must be :
- Random, like a UUID for example.
- Time-limited, so valid for no more than an hour or two
- Invalidated after use, to ensure that in the event of a leak it cannot be reused by an attacker
- Invalidated when a new reset request (concerning the same user) is made, to prevent an attacker from generating several tokens, which would make it easier for him to ‘guess’ one.
To find out more about this type of exploitation, please see our article: Exploring Password Reset Vulnerabilities and Security Best Practices.
Attacks on single sign-on (SSO) systems
SSO (or Single Sign-On) is a method of centralising authentication on a single server, enabling access to several services/applications with a single account. The best-known example is undoubtedly Google, which uses a single authentication form to generate a session token that gives you access to all its services (gmail, gmap, gdrive, etc.).
It’s also a very popular system with large companies, as it makes managing employees/users much easier by centralising everything in a single system.
Let’s take a quick look at how an SSO system works:
Due to its popularity, many applications now offer their customers the option of linking their corporate SSO to the application. However, if this is not implemented correctly, it can allow an attacker to completely compromise the entire authentication system.
Indeed, if a malicious actor is authorised to link his own SSO, he can configure it so that, during the “SSO->application” response after SSO login, he authorises the user to connect with a user who is not part of the SSO and over whom the malicious actor should have no rights:
If the application does not check that the token returned by the SSO server is valid and relates to an account under the jurisdiction of that SSO, an attacker can log in with an account that does not belong to him.
In general, any data coming from external SSOs should be considered as potentially manipulated and should therefore be checked carefully.
Reusing passwords: a goldmine for attackers
This case is not technically very complicated, but it does present a real challenge: everyone reuses their passwords. In fact, passwords are becoming increasingly complex over time, thanks to increasingly powerful computers (which can crack them more easily).
Today’s standard (according to the National Institute of Technology) is a password with a minimum of 8 characters and a maximum of 64, all types of characters authorised and with no consecutive repeating letters.
It is also strongly recommended not to rotate passwords, as users tend to use variants (password1, password2, password3, etc.), which does not increase security but encourages them to use shorter passwords.
Once all these conditions have been met, the password is generally not very easy to remember, which leads users to have only one or two different passwords on all their platforms.
However, some of these platforms will inevitably end up being hacked and their passwords will be freely available on the Internet.
Add to this the fact that many users use extremely simplistic and well-known passwords. In 2022 Google published a study showing that 24% of Americans use variants of abc123, Password, 123456, Iloveyou, 111111, Qwerty, Admin, and Welcome.
Mozilla has also published a paper showing that 59% of users use their name or date of birth in their passwords.
All these factors combined mean that an attacker, without even attacking the authentication system as such, already has a good chance of gaining access to a platform just by trying out known passwords.
The first solution to this problem is to set up 2FA. This way, even if the password is known, the attacker will not be able to gain access to the account.
In addition, encouraging users to use password managers is a good way of strengthening their security.
Conclusion
The authentication system is a tempting target for malicious actors because it is both the gateway and the keystone of the application.
Fortunately, the attack vectors on the authentication system have been clearly identified and there are standards which, if scrupulously followed, guarantee (as far as possible, of course) the security of users and the platform.
Author: Renaud CAYOL – Pentester @Vaadata