Broken authentication and session management

To authenticate means to prove that something is correct and valid.

In the IT world, authentication is a process that verifies or identifies if a user is actually who he claims to be. This protects systems, networks, devices or applications from unauthorised access or use as only legitimate authenticated users are allowed to access the resources.

Usually, user authentication is achieved by submitting a valid username or user ID and its corresponding private information (e.g. a password). The application then performs verification on the server-end to check whether the supplied information is correct and if so, the user is granted access.

If an organisation has broken authentication and session management mechanisms are not secure, cybercriminals can gain unauthorized access to their systems and steal sensitive information. Recent data leakages in Adobe, Equifax and Yahoo are excellent examples of what consequences can take place if an organisation fails to secure its authentication mechanisms.

What is broken authentication?

Broken authentication is the term given to attacks against an application’s login mechanism. Broadly, broken authentication attacks can be divided into two areas of weakness; credential management and session management. 

Functionalities such as password change, forgot password, remember my password, account update etc. are usually prime targets to exploit broken authentication issues. This issue is listed in both OWASP web application and API top 10 security risks.

Exploiting broken authentication and session management allows an attacker to hijack accounts/sessions, compromise passwords, steal keys and session IDs and impersonate users.

What is the difference between broken and broken access control?

Authentication bit answers the question, “Who are you?”  i.e. it validates if a user is allowed access to a certain resource. Whereas access control answers the question, “Are you allowed to do that?” i.e. after a user has been authenticated, whether she/he is authorised and has the permissions to carry out a certain operation.

Access control is the second phase in allowing a user access to any resource. It is the policy or set of permissions allocated to a user which governs what a user is allowed to do within that specific application or system. If access control is not set properly, then this can lead to the disclosure of sensitive information, modifications or deletion of data etc.

For example, a website has two types of users: an admin user and a support user.

The admin user is allowed to create, update and delete tickets, whereas the support user can only view them. In this scenario, if it is possible for a support user to create or delete tickets, then this will be a  bypass of the access control policies.  

What is session management?

Web applications assign each of their users a specific session ID. This is used to track and uniquely identify each user. Session IDs are used to maintain the state of the user and required the webserver to remember which user it is interacting with. These sessions are maintained by the server, and the session ID is sent with each request the user makes. 

What is broken authentication and session management is OWASP?

The Open Web Application Security Project (OWASP) is a non-profit foundation that aims to improve security for applications. They release their OWASP top 10 vulnerabilities list, which is a list of the most common and severe vulnerabilities found during that time period. The latest OWASP top 10 list rates broken authentication at number 2 in the list, as this is one of the most prevalent and dangerous threats as it allows attackers to steal user credentials, forge valid sessions, capture valid cookies and overall gain unauthorised access to websites.

What are some examples of broken authentication?

As discussed above, broken authentication attacks can be divided into two major areas of weakness: credential management (which will be discussed below) and session management (which will be discussed later on).

An example of broken authentication vulnerability is:

Credential stuffing

In a credential stuffing attack, the attacker gathers a list of credentials from available data breaches. The attacker then uses these password combinations to try to log in to another application. The concept behind this attack is that users use the same passwords across multiple applications, so a password leaked from one application can be used in another. Credential stuffing is a variant of the traditional brute force attack.

This attack is usually carried out through the help of bots that are used for automated credential stuffing brute forcing since the list of credentials is usually in millions.

Password spraying

This is another example of a broken authentication vulnerability where the attacker uses multiple iterations and attempts to log in using a single password against a large list of valid usernames. For example, the attacker tries the password against a list of valid users names, then on the second iteration, he tries another password against all the usernames and so on. Password spraying is also a type of brute forcing attack.

This type of attack helps to bypass the rate limiting or account lockout enforced in an application. If the application locks out a user after 3 incorrect attempts in one minute then the attacker can bypass this protection mechanism using password spraying.

Improper storage of credentials

More often than not user credentials are stored in databases. If these credentials stored are not protected via encryption or hashed and salted values then any insider or external attacker that gains access to the database can read and use the user credentials.

Predictable or weak passwords

If a system does not implement strong password policies, users may choose easy to guess and weak passwords or the system’s default credentials might not be changed after use. In such scenarios, it is easy for an attacker to guess user passwords and gain access to the system. 

What scenarios can cause broken authentication?

In broken authentication attacks, the goal of the hacker is to compromise or gain access to the victim’s accounts. This can take place due to a number of scenarios such as:

• The user credentials are not being protected when stored such as in the database. 
• The login credentials are predictable or default credentials are being used.
• The session tokens are being disclosed in URLs.
• The session tokens are vulnerable to attacks session fixation.
• The user sessions are not being properly invalidated after logout or the session does not time out after a certain duration.
• Credentials and session information is being transmitted over clear text using encrypted protocols.

What are session management attacks?

Misconfigurations and faulty implementation of session management can lead to a number of attack scenarios as discussed below:

Session hijacking

In a session hijacking attack, an attacker can gather session related information by different means. He can then later use the session IDs to login into the application as the victim himself and compromise the account.

An example of session hijacking is when credentials and session information (session ID) are sent over unencrypted channels such as HTTP and an attacker can capture the tokens.

Session ID URL rewriting

If an application is transmitting its session ID via getting request, i.e. the session IDs are being transmitted in the URL then they can become a target for URL rewriting. This happens when URLs are stored publicly in different locations on the internet and anyone can see them and reuse the session IDs to login to the application as the victim.

http://mybank.com/account/transfer;jsessionid=2P0OC2234SNDLJDKECJUN2JV?dest=1122568

Session fixation

Sometimes applications set random session IDs for both unauthenticated and authenticated users. For example, a user opens the application for the first time, he is given the session ID “abcd1234”, afterwards he enters his credentials and becomes an authenticated user of the application. 

A fixation attack on a session happens when an application does not change the session ID value upon successful authentication. Continuing in the above example, the session ID of the user after logging in would also be “abcd1234”. In such scenarios, the attacker may force the user to use a predetermined session ID (known to the attacker) and make a successful login to the application.

Improper login session timeouts

Applications should implement session expiry on logout and after a defined idle time period. Suppose a user logs on a public computer to access an application, after he is done with the work he simply closes the browser tab and walks away, forgetting to logout the application.

After he walks away an attacker uses the same browser an hour later to access the application and sees that the user is already logged in as his session did not expire. 

What is the impact of broken authentication and session management?

If an attacker is able to exploit the authentication mechanism of an application by any of the above-mentioned methods or more, he may be able to:

• Steal session ID and impersonate legit users.
• Steal user credentials.
• Steal critical data after accessing the system.
• Impersonate users and cause identity theft.
• Send fraudulent messages or emails.
• Create fraudulent transactions.
• Share fake news.
• Cause reputational damage to the organisation.
• And much more as the attacker would have complete control of the victim’s account.

How to Fix Broken Authentication?

Mitigation and preventive steps can be implemented to help protect an organisation’s authentication mechanism from broken authentication and session management attacks. Some of the best practices to prevent broken authentication and session management flaws are as follows:

Implement multi factor authentication

As mentioned above, organisations can not rely on passwords alone to secure their login session mechanism so to implement multi factor authentication (MFA) approach is the way to go.

A user should login with a password, if that is correct he should be presented with another item to enter (this is the multi factor). The value of multi factor authentication can be anything, a token sent by email, SMS or a hardware token, it can also be biometric verification such as the user’s fingerprint. 

The use of multi factor authentication to prevent an attacker from compromising a system’s authentication mechanism has become a widely used approach nowadays.

Use an SSL certificate

Web applications should implement SSL (secure socket layer) certificated to publicist websites using HTTPS. This is to protect against man-in-the-middle (MITM) attacks as SSL encrypts the communication to and from the web application and the webserver.

Enforce strong passwords

Brute force attacks can be prevented if the users are required to use a strong password. The password policies should take into account the following:

• Password Length should be at least 10 characters.
• Passwords should contain a mix of lowercase and uppercase letters, numbers and special characters.
• Passwords should not include dictionary words.
• Default credentials should be changed immediately.
• Passwords should not contain the user’s name, phone number, date of birth or any other guessable information.
• Passwords should be changed after a defined period (for e.g. 3 months).

We have written a detailed article on recommendations to secure your passwords and underlying assets such as servers.

Control session timeout

Depending upon the type of application, session timeouts should be implemented so that the user does not stay logged in even after he is done using the application. 

Rotate and invalidate session IDs

As discussed earlier, session IDs should be changed after a user successfully logs in to prevent session fixation attacks. Similarly, session IDs should be set properly invalidated during logout. 

Don’t put session IDs in the URLs

Avoid sending session ID via getting request parameters so that attacks e.g URL rewriting can be avoided and passwords session IDs are not leaked publicly.

Don’t store passwords in cleartext

Applications that store user credentials should do so in a secure manner. Such databases should be encrypted and the password should be stored as hashed and salted values.

Use breached password protection

Where possible applications should implement solutions that match user passwords against a known list of breached credentials so the user can be made aware and does not use the same credential. 

Implement brute force protection

The number of failed login attempts should be restricted so the user only has a fixed number of attempts in a defined time period. This will reduce the chances of a brute force attack and will also prevent additional load on the webserver as web traffic can increase to 180 times during a credential stuffing attack.

An account lockout should be initiated when a user reaches the maximum allowed requests.

Username and password enumeration

On incorrect logins, the application should not identify which part of the authentication was incorrect on failed login attempts instead the application should give a generic error response