API2:2023 Broken Authentication
Authentication in APIs is a complex topic, with software and security engineers often having misconceptions about what its boundaries are and how to implement it correctly. To make things even more challenging, prompting users or machines for credentials and additional authentication factors may not always be possible in direct API communication and authentication mechanisms are easy targets for attackers, particularly if they are fully exposed or public. These two points make the authentication component potentially vulnerable to advanced attacks that include brute-forcing of authentication, credential stuffing and credential cracking.
Problems with authentication in APIs usually stem from two issues:
- Lack of protection mechanisms - API endpoints that are responsible for authentication must be treated differently from regular endpoints and have extra layers of protection in place.
- 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.
There are also several technical factors that lead to broken authentication in APIs. These are the most common:
- 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 is exposed in URLs and GET requests.
- Authentication tokens with insufficient entropy.
- Use of API keys as the only authentication material.
- Failure to validate the 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.
Get the comprehensive list of best practices to guide your API security journey.
Download NowPotential Impact of a Broken Authentication Attack
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.
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 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.
What Does a Broken Authentication Attack Look Like?
Broken authentication is the second most critical API security threat listed in the OWASP API Security Top 10. Common examples of attacks targeting broken 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.
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: The Parler Data Breach
In 2021, Salt analysis of the Parler data breach found that the social media platform’s authentication was at least partially absent, supporting the general consensus among hacktivists and media outlets. This flaw, along with other security flaws in the Parler platform, enabled the scraping of at least 70TB of data before the platform got shut down on January 11, 2021, as it became clear that participants in the storming of the Capitol six days before had used it to coordinate their activities.
Hacktivists found that at least one API endpoint was available without any authentication requirement and several 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 a Twilio integration that was later decommissioned. Allegedly, some of the hacktivists that took part in the scraping of the platform’s data used this to bypass multifactor (MFA) authentication during account creation and extract data. This was later disputed by the hacktivists, and Twilio representatives have also stated it was false. An MFA misconfiguration would further fuel the debate about whether the Parler data was truly public, but there isn’t enough forensic evidence to support either claim.
Most media outlets have deemed the Parler security issues to be the result of poor coding. Although poor design choices and coding patterns have most likely played a part, dismissing the types of issues that led to the Parler breach as simply “poor coding” perpetuates the friction amongst developers, engineers, and security practitioners.
Modern application development and systems design is incredibly complex, and it requires many individuals in both security and non-security roles to work in sync to get a large-scale application working without issue. The problem is worsened when you consider the modern digital supply chain and how organizations outsource elements of IT wholesale or per project. Bugs and vulnerabilities are inevitable. However, we can continue to learn from these mistakes to improve the state of application security and API security.
Why Existing Tools Fail to Protect APIs Against Broken Authentication
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 your APIs Against Broken Authentication Attacks
To protect against broken 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.
To learn more about how Salt can help defend your organization from API risks, you can connect with a rep or schedule a personalized demo.
