Broken Authentication Explained | OWASP API2:2023

Despite many developers and teams feel confident about the security of their APIs, Broken Authentication is still one of the top API security risks according to the Open Worldwide Application Security Project (OWASP). In this article, we will understand why this issue is still so common and how we can prevent it in our systems. The same content is available in video format on my YouTube channel.

What is Authentication?

Authentication is the process of verifying the identity of users and applications that interact with our system. In simple terms, we want to know WHO or WHAT is invoking our API.

Unfortunately, authentication is easy to exploit. The Open Worldwide Application Security Project (OWASP) considers authentication the second highest API Security Risk in its top ten. Let’s see why.

Authentication is easy to exploit because it’s exposed to everyone, and several automated exploitation tools are available.

It’s extremely common because authentication standards are often misunderstood by developers and architects alike.

The impact of broken authentication is extremely severe since the attackers can impersonate legit users, take control of their accounts, and extrapolate sensitive data.

The only positive note is that detecting authentication issues should be fairly easy with existent methodologies.

The way authentication is broken are multiple and OWASP lists 12 potential vulnerabilities. I think there are many more. However, let’s divide them into three groups:

• Poor Standards and Practices
• Automated Attacks
• Sensitive Functions

Poor Standards and Practices

The biggest threat to API security is us. That’s why I’ll state very clearly that we should avoid custom code at all costs. Security is complex and the chances of creating a weak authentication system with multiple vulnerabilities are very high.

For instance, never ever enforce authentication at the function level. We must use certified or well-known libraries or solutions that enforce authentication at the component or system level. I would suggest placing an API Gateway in front of our applications so we can enforce authentication right there; at the entry point of our system.

However, even the best solution cannot protect us from bad practices and misuse. We need to have a solid understanding of the authentication scheme we are using.

For example, if we decide to use OAuth and OpenID Connect in conjunction with Json Web Tokens, we need to make sure that all tokens are signed properly by the Identity Provider and validated for authenticity and expiration by our system.

I know what I’m saying sounds obvious, but most successful attacks leverage these vulnerabilities. Even large companies with incredible brainpower are not immune from mistakes and are breached.

This is a list of things you might want to double check when it comes to authentication. I’ll share it on my website so you can consult it later.

Automated Attacks

Another common way to break authentication is through automated attacks. There are many types. However, the solutions we use to mitigate them are the same. That’s why we can group them together.

Brute Force tests multiple passwords from a dictionary against a single account.

Credential Stuffing tests username/password combinations obtained from the breach of another site, or maybe from an internal leak.

Password Spraying tests a single weak password against many accounts.

So how do we deal with these attacks?

Rate limiting, banning TOR and Proxy IPs could be considered a good mitigation strategy because it slows down a potential attacker. However, despite these attacks are often automated, they do not necessarily spam our APIs, especially when attempting credential stuffing.

The best defense is Multi-Factor Authentication (MFA) where a user needs to provide more than one verification factor. A factor in authentication is a way of confirming our identities when we sign in. Factors are divided in three categories:

• Something you know which includes the password or a PIN.
• Something you have like a smartphone or secure USB Key.
• Something you are like a fingerprint or facial recognition.

This prevents a malicious actor with a valid password combination to takeover an account. There’s a famous post by Alex Weinert, currently VP of Identity Security at Microsoft, titled “Your Password doesn’t matter”. He argues that our accounts are 99.9% less likely to be compromised if we use MFA. He also mentions FIDO2 which is a form of password-less authentication but that’s a topic for another video.

Sensitive Functions

Ensuring the security of authentication involves safeguarding all sensitive functions directly linked to it.

Forgot or Recovery Password must be protected as login endpoint in terms of brute force, rate limiting, and lockout protections. It’s a source of many vulnerabilities, the most common being the user enumeration attack.

This happens when our system gives a clear indication to a malicious actor about the existence of a username. To prevent it we need to return a consistent message for both existent and non-existent accounts. There are also other precautions we need to consider, some of which might sound improbable, but they can be exploited. For example, we need to make sure that the time taken to give a response back to the attacker is the same whether a username exists or not.

It’s also important to force reauthentication for actions where we modify the contact details or credentials of a user, especially if we are using token-based authentication.

In standards like OAuth or OpenID Connect, the password is exchanged for an access token that has limited scope and expiry. This is done to reduce the impact caused by a stolen token and to avoid sharing the password with third-party applications trying to access our accounts. That said, we must perform a second factor of authentication any time the user attempts to change his email or password to make sure that we are dealing with the legit user and not a malicious actor who has successfully stolen a token.

Conclusion

Let’s sum it all up!

What we learnt is that authentication is not something we can improvise. Custom code is not allowed! We need to use standards implemented by certified solutions and libraries that enforce authentication at a system level. We also need to understand these standards. It’s a good idea to have regular training or brainstorming sessions on these topics with your teams.

Multi-Factor Authentication is a must. If you’re serious about security, you should enforce MFA across all your accounts. This might cause friction with business. They might argue that it’s detrimental to the user experience. However, ask them if they would change their opinion should their system suffer a breach. Prevention is better than cure.

Make sure to take precautions for sensitive operations like reset password or change email.

And the most important thing is… don’t forget to share this article so that everyone can learn something new!