OWASP Top 10 2017: A2 Broken Authentication

June 15th, 2017

OWASP Top 10 2017 – A2 Broken Authentication

Authentication and session management includes verifying user credentials and managing their active sessions. Broken authentication and session management occurs when credentials cannot be authenticated and session IDs cannot be initiated due to lack of encryption and/or weak session management. These flaws create vulnerabilities that not only risk confidential data but entire company systems and networks by users impersonating other users, for instance. It takes just one stolen permission to infiltrate and damage your company’s viability.

Authentication and Session Management Basics

The rather straightforward authentication process precedes opening user sessions. Authentication occurs when provided credentials are successfully matched against an authorized user database. The user session can then be initiated once credentials are authorized. Session IDs, also known as session identifiers and session tokens, are unique identifiers (cookies) stored and sent by the server to the client.

Session management workflow looks something like this:

A user delivers login information (submits credentials)
Credentials are authenticated by token (smart card), password or biometrics (fingerprint, retinal scans)
A session and relevant IDs are issued and cookies are delivered
The user carries out the workflow
At some point, the user may need credentials re-authenticated (i.e. user walks away for a time)
The user will log off the session, ending it, or there might be an idle session timeout
The session will time out due to idleness or predetermined time constraint (called an absolute session)
The session, therefore, becomes invalidated due to user log out or session timeout

Any deviation from the authentication and session management process can lead to brokenness, flaws, and potentially severe technical impacts as all user accounts in your company, including privileged accounts, can be breached both internally and externally.

Authentication and Vulnerability Issues

Issues tend to be widespread, but are detectable. It sounds easy to discover a flaw–put in a bad password and you don’t log in to the page you seek. The issues go deeper than mere login credentials being rejected. Often problems lie with development and custom code which makes detection and issue resolution more difficult.

Common authentication flaws include user names and passwords. For example:

Poor password management: password simplicity and reuse, stored credentials leave user credentials unprotected. Also, forgotten password and change password features that are sent over email or are given through weak authentication policy.
Weakened account management leaves credentials exposed to “brute force” guessing and overwrites. Your user accounts can be accosted with many password guesses for one account or one password guess for multiple accounts.
Session IDs vulnerabilities: IDs exposed in URL, lack of timeouts, unlimited password tries, or session sign-on tokens that are not invalidated upon logout, and unrotated, validated session ID logins are just some of the flaws that can create exposure.
Unencrypted and weakly encrypted connections are a major security risk.

Two issues take these one step further :

Computer system customization–developers have to custom build logins, logouts, password management and workflow processes, including timeouts. This type of development is difficult and weaknesses occur easily due to human error.
Utilizing the cloud, IoT, and mobile devices add extra chances for authentication errors, especially for mobile devices that are used for one employee and then another employee without changing credential criteria.

It is most important to properly protect your company user sessions throughout their life cycle through consistent authentication and session management checks and testing, i.e. penetration testing.

Resolving Broken Authentication and Session Management Issues

How is broken authentication and session management different from broken access controls? Broken access controls involve vulnerabilities in authorization while broken authentication involves verifying the identity of a user before the user is authorized to have the session. While off the top they seem very similar, these two issues have very different processes, vulnerabilities, and resolutions, and shouldn’t be confused.

There are several ways broken authentication and session management can be resolved. Here are 3 common problems and their resolutions:

Problem 1: authentication match to authentication list is not enough security.

Resolution: Create a two-factor authentication process. Use a token and password, for instance. Remove any default passwords and make sure that recovery paths do not show current passwords.

Problem 2: sessions are not timing out after inactivity.

Resolution: establish inactivity timeout by adding a functional time (i.e. 1 to 2 minutes) notice that the session will time out due to inactivity. This prompt will allow the user time to become active within the session or to log out.

Problem 3: The user wants to log in to a site, not on the company safe list.

Resolution: Web Application Firewalls (WAFs) can mitigate session attacks by protecting HTTP applications from infiltration in case a user tries to log in to a potentially unsafe site.

There are innumerable ways that broken authentication can lead to insecure session management. Every issue and vulnerability is unique as is its resolution and should be handled on a case-by-case basis.

Prevention Is Key

Everyone knows it is easier to prevent than to fix an issue.

The key to resolving broken authentication and session management is that authentication controls must be implemented centrally. This will prevent many issues since all web servers, application servers and other computing environments will have just one location that establishes and feeds the authentication and session management process.

Some key preventive measures include:

Passwords: strength, use, change controls, storage. Password strength should be complex, non-worded, alphanumeric with approved special characters, at least 8 to 15 characters long and changed periodically. Often the system will prompt for password change and let you know when a password is set to expire.
Use information: a predetermined amount of login attempts and no mention of whether the username or password was wrong. Change controls should include providing both the old and the new password and re-authenticating the user should the password or username be emailed.
Protecting Credentials in Transit can only be accomplished by encryption through Secure Socket Layer (SSL).
Session ID protection, using SSL. Never use session IDs in the URL as they can be easily cached or passed to another user. Make session IDs long, boring and complicated random numbers and change them frequently to reduce the length of their validity (e.g. timing out). Never accept session IDs initiated by an individual user.
The account list should not be available for access to users. If they must see who is on the site, use a pseudonym (screen name) that can lead to particular accounts.
Do not browser cache. All it takes is the back button to resubmit login credentials in many browsers. This
Your site architecture should not implicitly trust among components. Components should be self authenticated because site architecture evolves and trust can be breached.
Avoid cross-site scripting flaws, they can steal session IDs.

Developers should always have one set of strong authentication and session controls given to them by their company as there needs to be constant maintenance and testing so that broken authentication and session management issues and the subsequent risks are circumvented