Skip to main content

A2 Broken Authentication

Definition​

Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities temporarily or permanently.

Risk Factor Summary​

  • Score: 7.0
  • Attack Vectors Exploitability: 3
  • Security Weakness Prevalence: 2
  • Security Weakness Detectability: 2
  • Impact Technical: 3

Context​

Attackers have access to hundreds of millions of valid username and password combinations for credential stuffing, default administrative account lists, automated brute force, and dictionary attack tools. Session management attacks are well understood, particularly in relation to unexpired session tokens.

The prevalence of broken authentication is widespread due to the design and implementation of most identity and access controls. Session management is the bedrock of authentication and access controls, and is present in all stateful applications.

Attackers can detect broken authentication using manual means and exploit them using automated tools with password lists and dictionary attacks.

Attackers have to gain access to only a few accounts, or just one admin account to compromise the system. Depending on the domain of the application, this may allow money laundering, social security fraud, and identity theft, or disclose legally protected highly sensitive information.

Is the Application Vulnerable?​

Confirmation of the user's identity, authentication, and session management are critical to protect against authentication-related attacks. There may be authentication weaknesses if the application:

  • Permits automated attacks such as credential stuffing, where the attacker has a list of valid usernames and passwords.
  • Permits brute force or other automated attacks.
  • Permits default, weak, or well-known passwords, such as "Password1" or "admin/admin“.
  • Uses weak or ineffective credential recovery and forgotpassword processes, such as "knowledge-based answers", which cannot be made safe.
  • Uses plain text, encrypted, or weakly hashed passwords (see A3:2017-Sensitive Data Exposure).
  • Has missing or ineffective multi-factor authentication.
  • Exposes Session IDs in the URL (e.g., URL rewriting).
  • Does not rotate Session IDs after successful login.
  • Does not properly invalidate Session IDs. User sessions or authentication tokens (particularly single sign-on (SSO) tokens) aren’t properly invalidated during logout or a period of inactivity.

Conceptual Attacks​

Scenario #1:​

Credential stuffing, the use of lists of known passwords, is a common attack. If an application does not implement automated threat or credential stuffing protections, the application can be used as a password oracle to determine if the credentials are valid.

Scenario #2:​

Most authentication attacks occur due to the continued use of passwords as a sole factor. Once considered best practices, password rotation and complexity requirements are viewed as encouraging users to use, and reuse, weak passwords. Organizations are recommended to stop these practices per NIST 800-63 and use multi-factor authentication.

Scenario #3:​

Application session timeouts aren’t set properly. A user uses a public computer to access an application. Instead of selecting “logout” the user simply closes the browser tab and walks away. An attacker uses the same browser an hour later, and the user is still authenticated.

Example Attack Scenarios​

Passwords are not properly hashed and salted:​

NEVER Store a password in plain text.

Some good practices to store passwords:

    1. Validate the password strength
    1. Use bcrypt with a high cost (>=15) or a secure salt system to generate the password hash.
    1. Optional: Force the users to change the password every 90 days maximum.

Extra features:

const bcrypt = require('bcrypt'); //https://www.npmjs.com/package/bcrypt
const saltRounds = 15;

const isPassStrong = (pass) => {
    // @see: https://www.thepolyglotdeveloper.com/2015/05/use-regex-to-test-password-strength-in-javascript/
    const criteria = new RegExp("^(?=.*[a-z])(?=.*[A-Z])(?=.*[0-9])(?=.*[!@#\$%\^&\*])(?=.{8,})"
    return criteria.test(pass)
}

const hashPass = async (pass) => {
    if(!isPassStrong(pass)) throw new Error("The password is weak!")
    bcrypt.hash(pass, saltRounds, (err, hash) => {
        if(err) throw err;
        return hash
    });
}

Session IDs in the URL:​

This example is based on Scott Smith example about Authentication and sessions

NEVER use the session ID in the URL as your application will be very vulnerable:

  • Much more visible and thus more dangerous and the sharing of link grants others full access
  • Stored on cache servers and browser history
  • Leaked through the Referer header and logs not properly protected

Some good practices to manage session IDs:

  • You can use cookies for session
  • You can use Authentication headers if you are using JWT or similar
  • You need to ensure that all the traffic is handled using https
  • If you are using cookies, please ensure that you use secure and httpOnly flags.
  • As well ensure that you are using Strict Transport Security (HSTS).
  • If you are using a proxy don't forget to enable trust proxy in Express

Extra:

const express = require('express');
const session = require('express-session');
const helmet  = require('helmet');
const {secretSession} = require('./config).express

const app = express();

// HSTS
app.use(helmet.hsts({
  maxAge: 7776000000, // 90 days
  includeSubdomains: true
}));

// Proxy setup
app.set('trust proxy', 1);

// Cookie session details
app.use(session({
  secret: 'secret session secret',
  cookie: {
    maxAge: 3600000, // 2 hours in milliseconds
    secure: true,
    httpOnly: true
  }
}));

app.listen(8080);

How to Prevent​

  • Where possible, implement multi-factor authentication to prevent automated, credential stuffing, brute force, and stolen credential re-use attacks.
  • Do not ship or deploy with any default credentials, particularly for admin users.
  • Implement weak-password checks, such as testing new or changed passwords against a list of the top 10000 worst passwords.
  • Align password length, complexity and rotation policies with NIST 800-63 B's guidelines in section 5.1.1 for Memorized Secrets or other modern, evidence based password policies.
  • Ensure registration, credential recovery, and API pathways are hardened against account enumeration attacks by using the same messages for all outcomes.
  • Limit or increasingly delay failed login attempts. Log all failures and alert administrators when credential stuffing, brute force, or other attacks are detected.
  • Use a server-side, secure, built-in session manager that generates a new random session ID with high entropy after login. Session IDs should not be in the URL, be securely stored and invalidated after logout, idle, and absolute timeouts.

Hacking Playground​

References​

OWASP​

CWEs​

Other​