Broken User Authentication

User authentication is at the core of using APIs safely. It allows administrators to access the API and secured resources while preventing regular users from accessing these secured resources, as well as other users’ data. If the backbone of this authentication system is broken, the potential for data leaks, modification, deletion, and even account takeover will be present, ready for exploitation by malicious actors. When authentication is poorly implemented any user can take on the identity of another.

What does that mean?

In more concrete terms, broken user authentication reflects when an API should have an authentication system but does not in practice, or that the implemented authentication fails in some cases, allowing attackers to impersonate an authenticated user. The reason for this is that authentication systems are complex, and due to the public-facing nature of these systems (so the public can log in), the system is exposed to attacks.

There are several aspects concerning the vulnerabilities around these authentication systems. The first is that the design may be insufficiently restrictive in case of a series of failed authentication attempts. This includes lacking the implementation of captchas or cooldowns to prevent brute-forcing, not having multi-factor authentication methods (to address credential stuffing) or allowing previously-leaked passwords (such as any mentioned on haveibeenpwned), sending sensitive information through unencrypted channels and potentially in plain view (i.e. in URLs), or using weak encryption keys. It is also possible that the authentication mechanism has these features, but they have been improperly implemented, which provides room for circumvention or attack of the authentication system.

What makes an API vulnerable to this type of bug?

One attack vector for API authorization is the ever-present API Key. Private keys are designed to be secret but may be found left in erroneous git commits. While API keys are designed for use in authentication capacities, there have been instances where they have been used in authorization roles. Therefore, if an API key can be found by a third party, they might be able to access resources that they are not supposed to. API keys can be found in different ways: “Google Dorking”, and looking for APIs that generate or use tokens without securing them.

The type of file sought after can be documents containing sensitive information stored in plaintext, such as user accounts login information or API keys. This is another way that user authentication can be circumvented, pointing to inadequate implementation of the authentication system. This is of particular concern when securing internal APIs, as developers operate under the assumption that they will not be found by an external actor, as opposed to the public-facing API.

Fundamentally resolving authentication vulnerabilities is completed by ensuring robust authentication mechanisms, using standards such as OAuth (helping to avoid the incomplete or inadequate implementation), implementing multi-factor authentication, account lockout and captchas, and weak password checking features. Finally, various tools can detect a potential hard-coded API key for 3rd party services such as Google Maps.

What can attackers do by going around broken authentication systems?

Authentication is at the heart of many APIs, and these issues can affect everyone from developers accidentally committing API keys, allowing for pay-per-use APIs to be abused, or mechanisms like OAuth being misconfigured allowing an attacker to take on the identity of another user. There are even tools that can figure out how to abuse an API such as keyhacks and even GitHub will try to ensure API keys are kept private.

How can you avoid having a broken user authentication system?

OWASP proposes several steps to undertake to effectively prevent the breaking of user authentication mechanisms for APIs. The first is understanding the API authentication routes; as security engineers and developers may be different people, both parties need to be clear about how the specific API authentication system works. Other steps are some that we – as users – see everywhere on the web: implementing multi-factor authentication, anti-brute-forcing mechanisms applied to authentication, and password reset endpoints. That’s why we fill Captchas and see login cooldowns on websites! The correct application and implementation of authentication mechanisms such as OAuth by reading the relevant documentation and setting up authentication systems to existing standards are essential. As OWASP puts it: “Don’t reinvent the wheel in authentication, token generation, password storage.”

When it comes to API security, it’s about who you are, not who you know.