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:
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.
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:
- 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
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.
Authentication factors can be classified into different groups such as something you know, you have, you are or you do.
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:
- Insufficient protection against brute-force attacks and missing rate-limit make the authentication mechanism weak.
- 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.
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 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.“
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.
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:
- The attacker requests a password reset mail on behalf of Carlos.
- The attacker intercepts the request and injects a Host header with his malicious server address.
- Since the web application trusts the Host header, the password reset link points to the attacker’s server.
- When Carlos clicks that link, the password reset token will be obtained by the attacker.
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.
An application has a login function and two levels of privileges:
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.
An attacker can take over an unregistered user account via the methods following.
- Go to the target website and sign up using the unregistered victim's account.
- The application may or may not ask for email verification.
- After a while, the victim signs up using no password methods/protocols.
- 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.
- Go to the target website and sign up using a no password method.
- Change your email address to the victim's email address.
- After a while, the victim tries to sign-up using email registration and the application responds with a “User already exists!” message.
- The victim requests a password reset mail and changes his password.
- 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.
- Assume that you have an account on example.com, and request a password reset link.
- Do not use the link and sign in to your account.
- Change your email address.
- Go back to your inbox and change your password by using the reset link you requested in step 1.
- See that you can change your password via a password reset link linked to your old email address which you no longer use.
Assume that the target application takes usernames from users while registering and usernames are case-sensitive.
- Navigate the registration page and try to register with the username “admin”.
- If you get a message like “User already exists!”, then try signing up with username “Admin” or “AdmiN”, etc.
- Observe that you likely have now admin privileges.
- 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.
- 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)
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
- 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.
Re-authentication for sensitive functions plays a key role in mitigating CSRF attacks.
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.
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.
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.
Multi-factor authentication (MFA) is by far the best defense against the majority of password-related attacks, including brute-force attacks.
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.
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.
All failures including all failed login attempts and account lockouts must be logged and monitored in real-time to detect any attack intentions.
Use standard authentication protocols that can protect you from exposing your users' data to attackers.
- Open Authorization (OAuth)
- Security Assertion Markup Language (SAML)
- The Fast Identity Online (FIDO) Alliance
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 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).
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.