OWASP Top 10: Broken Authentication (A2:2017)

24th May 2021 ‧ By Simon Bell ‧ Category: Web Application Security

8 min read

Picture of an unlocked (open) padlock on a door

This is part of my OWASP Top 10 series covering the top 10 most critical web application security risks. If you've missed any of the previous security risks, check out the intro and overview.

Risk Rating

Exploitability: 3

Prevalence: 2

Detectability: 2

Technical: 3

Threat Agents	Exploitability	Weakness Prevalence	Weakness Detectability	Technical Impacts	Business Impacts
Application Specific	Easy: 3	Widespread: 3	Easy: 3	Severe: 3	Business Specific
	Average: 2	Common: 2	Average: 2	Moderate: 2
	Difficult: 1	Uncommon: 1	Difficult: 1	Minor: 1

OWASP's Risk Rating Methodology

What is broken authentication?

Broken authentication covers numerous vulnerabilities whereby an attacker impersonates a legitimate user. A broken authentication attack typically exploits a weaknesses in two main areas: session management and credential management.

Session management involves keeping track of a user's session as they move around a website. Let's say Alice logs into her bank then navigates to her accounts overview page. She then navigates to the send money page. The bank's server tracked Alice's session across those pages, keeping her logged in. But if someone else, say Mallory, hijacked Alice's session, then Mallory could impersonate Alice.

Credential management involves how users are authenticated to a website. The majority of websites authenticate uses through a username and password. The username identifies the individual user (e.g. Bob) and the password (known only by the user - in theory) verifies the user. But what happens when someone other than Bob -- say, Mallory -- knows Bob's username and password? Well, Mallory could impersonate Bob.

Examples of broken authentication

Session hijacking

Web server's track user sessions through session IDs. If an attacker gets hold of a user's session ID, then the attacker might be able to carry out a session hijack. A really simple example is when Alice a public computer to log in to a website (such as her bank). If Alice doesn't log out when she's finished, the Mallory could continue Alice's session - accessing Alice's bank account.

Session ID URL Rewriting

Some websites include a user's session ID in the URL. Let's say Alice logs into her bank, then views her accounts overview page. The URL might look like this:

http://yourBank.com.account-overview.html?sessionID=123456789

Now, imagine a malicious user, Mallory, on the same network sees your network data (such as on a WiFi connection). Mallory can now add Alice's session ID to her own request to the bank, and takeover Alice's session.

Session Fixation

Most websites assign a session ID to every user - even before they're logged in. When Bob visits his bank's website, he might be assigned the session ID 123456789 - even when browsing the homepage. When Bob logs in, his session ID might remain as 123456789 and the server notes that his session is now authenticated to his user account.

But what happens if the attacker, Mallory, can predetermine the session ID before Bob visits his bank? Mallory could send Bob a link to his bank containing the predetermined session ID. When Bob logs into his bank, his session ID remains unchanged from that which Mallory determined. Therefore Mallory can use the predetermined session ID to impersonate Bob.

Credential Stuffing

In 2013, Adobe suffered what was, at the time, one of the worst user account data breaches. Since then, the trend of large customer database leaks has, unfortunately, continued. In many cases, the passwords from these breaches can be extracted. Now, as an attacker, if you have such a list of passwords, you can use bots to automatically brute-force login attempts using said credentials. This technique is especially effective when people use the same password across multiple websites.

Password Spraying

Similar to credential stuffing, but this technique uses weak or common passwords as its data source. Passwords such as "123456" or "password" can often get attackers past authentication barriers when users have set weak or common passwords.

Phishing

Phishing attacks involve an attacker sending an email, SMS, or some other message, pretending to be from a trusted source. Phishing attacks might include a link to log in or enter other personal information on the website they're masquerading as. Phishing attacks provide attackers with another source of user credentials.

What's the impact of broken authentication?

If an attacker gains access to a single privileged account, such as admin, then a system may be compromised. Admin accounts often have access to actions and features that regular user don't. This might include things such as access to all data, modification of system-wide settings, etc.

Breached user accounts could lead to any number of issues such as identity fraud, money laundering, identity theft, etc.

How to defend against broken authentication

Control Session Length

Every user session needs to end at some point. Usually it's when the user logs out. Sessions should also time out after a certain period of inactivity or length of time. Session duration depends on the application and risk assessment of the organisation. A social networking site, like Twitter, might want longer session lengths to keep users engaged. Whereas a bank, with higher risks, might want to limit user lengths.

Random Session IDs with High Entropy

Sessions should be managed securely on the server-side. Session IDs should be generated randomly and with high entropy. This should reduce the chances of an attacker randomly guessing a user's session ID.

Rotate and Invalidate Session IDs

To prevent against session fixation, new sessions IDs should be assigned after a user logs in. Once a session ends the session and authentication tokens must be immediately invalidated so they can't be reused by an attacker.

Keep Session IDs out of URLs

There's no need to include session IDs in URLs. It'll only cause security problems. Store session IDs in cookies with flags HttpOnly (to prevent access through client-side scripts - reducing chances of XSS) and Secure (cookie only sent over HTTPS - to prevent session leaking).

Use MFA or 2FA

Multi-factor or two-factor authentication requires two or more verification factors to pass authorisation. Single-factor authentication only requires one factor, such as a password (knowledge; something the user knows). If a malicious user also knows this password, then user authentication fails. Additional factors typically include things you have (possession; such as badge or smartphone) and things you are (inherence; such as biometric fingerprints or voice recognition). Using two or more additional verification factors decreases the likelihood of a successful cyber attack. Even if an attacker knows someone's password, they will also need the other factor(s) to pass authentication.

Don't Allow Weak Passwords

Website's authentication systems should prevent users from setting passwords like "123456" or "password". Accounts should also be prevented from using the most common passwords on the web. OWASP recommends following NIST guidelines on password length and security.

Implement Breached Password Protection

In some cases, authentication systems can check if a user's password has appeared in a breach. The user can be notified and their account locked until their password is changed. Preventing attackers from using the leaked credentials to access the user's account.

Store Passwords Securely

Never store passwords in plaintext. Ever. Cryptographic hashing should be used to store passwords, along with salts. Hashing takes the user's password as input, and produces a random string as output. This process is irreversible. Therefore an attacker cannot determine a password when looking at its hash. However, if two users have the same password, their hash will be the same. So this is where salts come in: random data is added to the input password to ensure the output is unique.

Implement Brute-Force Protection

Limit the amount of login attempts each user can make to prevent credential stuffing attacks. Limits could be based on IP, session, browser fingerprint, etc.