API Security Evaluation Guide

Read the guide

API2:2019 Broken User Authentication

Michael IsbitskiMichael Isbitski
Feb 2, 2021

Description

Authentication in APIs is a complex and confusing topic. Software and security engineers might have misconceptions about what the boundaries of authentication are and how to correctly implement it. Prompting users or machines for credentials and additional authentication factors may also not be possible in direct API communication. In addition, authentication mechanisms are easy targets for attackers, particularly if the authentication mechanisms are fully exposed or public. These two points make the authentication component potentially vulnerable to many exploits. Advanced attacks that target authentication include brute-forcing (of authentication), credential stuffing and credential cracking.

Authentication in APIs has two sub-issues: 

  1. Lack of protection mechanisms - API endpoints that are responsible for authentication must be treated differently from regular endpoints and implement extra layers of protection.
  2. Misimplementation of the mechanism - The mechanism is used or implemented without considering the attack vectors, or the mechanism is not appropriate for the use case. As an example, an authentication mechanism designed for IoT devices is typically not the right choice for a web application like an eCommerce site.

Technical factors leading to broken authentication in APIs are numerous and include: 

  • Weak password complexity
  • Short or missing password history
  • Excessively high or missing account lockout thresholds
  • Failure to provision unique certificates per device in certificate-based authentication
  • Excessively long durations for password and certificate rotations
  • Authentication material exposed in URLs and GET requests
  • Authentication tokens with insufficient entropy
  • Use of API keys as the only authentication material
  • Failure to validate authenticity of authentication material
  • Insecure JSON Web token (JWT) configuration such as use of weak digital signature algorithm or missing signatures
  • Use of small key sizes in encryption or hashing algorithms
  • Use of weak or broken ciphers
  • Use of algorithms that are inappropriate for the use case, such as use of hashing algorithms rather than  password-based key derivation functions (PBKDF).
  • Failure to step-up authentication if authentication flows are being targeted, such as dynamically challenging with CAPTCHA or second factor authentication (2FA) material.

Learn how app architecture and attack surfaces are changing, how app security needs to evolve, and how to empower security.

Potential Impact

An attacker who is able to successfully exploit vulnerabilities in authentication mechanisms can take over user accounts, gain unauthorized access to another user’s data, or make unauthorized transactions as another user. Similarly, APIs may be designed explicitly for machine communication, or direct API communication. An attacker who compromises that authentication mechanism or authenticated session can potentially gain access to all of the data that machine identity is entitled to access. There are also variants of this type of attack in cloud-native design with compromises of workload authentication and server-side API metadata services. 

Example

Common examples of attacks targeting broken user authentication include API enumeration and brute-forcing attacks that make high volumes of API requests with minor changes. These attacks may also target broken or weak authentication. 

As an example, password recovery mechanisms often send an SMS to a user’s phone with a reset token consisting of a series of numbers. An attacker can initiate a password reset, and if the API does not implement rate limiting, the attacker can enumerate (or “guess”) the password reset token until they get a successful response. Depending on the throughput of the target API endpoint, an attacker may be able to iterate through thousands or millions of different combinations within a few minutes.

Real World Example

Unpacking the Parler Data Breach

In 2021, Salt analysis of the Parler data breach and the general consensus of media outlets and hacktivists found that Parler’s authentication was at least partially absent. This flaw, along with other security flaws in the Parler platform, enabled the scraping of at least 70TB of data. Based on what the hacktivist shared publicly, at least one endpoint was available without authentication which provided access to user data without requiring authentication. In Parler’s case, these APIs likely were not intended to be anonymous, public APIs. The APIs allowed direct access to Parler user profile information and user content, including message posts, images, and videos. It is unlikely that Parler would have intended or configured these APIs and pages to be accessible without authentication. 

Some reports indicated there was a security misconfiguration as a result of Twilio integration that was later decommissioned. Allegedly, some of the archivists used this to bypass multifactor (MFA) authentication during account creation and extract data. The issue was later disputed by the hacktivist, and Twilio representatives have also stated it was false. An MFA misconfiguration would further fuel the debate whether the Parler data was truly public and Parler APIs were lacking authentication. 

Why Existing Tools Fail to Protect You

Traditional security controls like WAFs don’t typically enforce authentication at a granular level and may only verify presence of a session identifier or authentication token in a given request. API gateways may enforce authentication as part of API management access control policies, but that presumes owning teams have defined policy appropriately. There is often an operational breakdown between teams creating APIs, teams publishing APIs, and teams securing APIs. Even still, API gateways lack understanding of what authentication is proper for an API in a given use case. Traditional security controls also lack capabilities to track attack traffic over time, which is necessary to decipher the different forms of advanced attacks targeting authentication such as credential stuffing and credential cracking. They will often rely on excessive API consumption rates to identify basic brute-force attack attempts.

How to Protect Against Broken User Authentication Attacks

In order to protect against broken user authentication attacks, an API security solution must be able to profile the typical authentication sequence for every API flow. The solution can then detect abnormal behavior such as missing credentials, missing authentication factors, or authentication calls that are out of sequence. Determining the baseline and identifying abnormal behavior can only be done by analyzing large amounts of production API traffic. This form of analysis is critical for mitigating advanced attacks that target authentication such as credential stuffing and credential cracking.


Previous post:

API1:2019 Broken Object Level Authorization

Next posts:

API3:2019 Excessive Data Exposure

API4:2019 Lack of Resources & Rate Limiting

API5:2019 Broken Function Level Authorization

API6:2019 Mass Assignment

API7:2019 Security Misconfiguration

API8:2019 Injection

API9:2019 Improper Assets Management

API10:2019 Insufficient Logging & Monitoring

Go back to blog