Broken Authentication

OWASP Top 10 - A2



What is Broken authentication?

These types of weaknesses can allow an attacker to either capture or bypass the authentication methods that are used by a web 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 forgot-password 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.

The goal of an attack is to take over one or more accounts and for the attacker to get the same privileges as the attacked user.


Broken authentication examples

Example #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.

Example #2: 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 #3: Passwords are not properly hashed and salted

An insider or external attacker gains access to the system’s password database. User passwords are not properly hashed and salted, exposing every user’s password.

Risk

  • Stored username and password values should be salted and hashed, in addition to being encrypted.


How to prevent Broken Authentication

Broken authentication

  • 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.

How Hdiv protects against A2 risk

Risk Covered

  • Hdiv detects the use of hardcoded keys and passwords within the code, too long session timeouts, session and URL rewriting, weak passwords, if HttpOnly flag is being used to session handling header, plus others; and protects applications against brute force login attacks and does not allow access to unauthorized resources thanks to its information flow control.
Explore our Online Demo