API2:2019 Broken User Authentication

In the previous post we covered API1:2019 Broken Object Level Authorization, which was the first post in this series. Feel free to start there and work your way back to here if you want! Or just keep on reading.

You can read the official document from the OWASP Project team here.

Broken User Authentication is a vulnerability that can affect any web app or API that has user accounts, which is a very large percentage of applications currently on the internet. The app or API asks the user “Who are you?” (authentication) and if the user is able to trick the app into ‘recognizing them’ when they are not a valid user, that is broken authentication.

When someone exploits this vulnerability, they have access to a system they should not, and quite likely, sensitive data of that user, plus the ability to change account settings of whatever account they have broken into. This is a total nightmare for the user whose account has been compromised, not only the security team.

The most common ways this vulnerability is exploited would be via credential stuffing (trying thousands of stolen credentials to see if any of them work), and brute force attacks (allowing end users to try over and over again to guess a password and not locking them out when they deserve it).

Other types of attacks of this nature include:

• Allowing users to make very weak passwords, such as “Winter2023”, which is likely the English-speaking-world’s most popular password this very moment. </sigh>
• Sending auth-tokens in insecure ways, such as in an unencrypted/insecurely configured cookie, or the URL parameters
• Not checking if your auth tokens are valid, every-single-call/page/action/time
• Using auth tokens incorrectly/with poor config/very old versions they shouldn’t use anymore
• Following all the right programming steps, but then sending it using very insecure encryption, such that it the data can be decrypted
• Insecure storage of passwords (passwords should be salted and hashed, possibly peppered, but never plain text or encrypted)

How can I ensure this never happens?

• Follow auth best practices and *ideally* use an API gateway. API Gateways can handle a lot of this for you, and that makes life WAY BETTER. Writing your own is very complex, time consuming, and potentially risky.
• Test. Test this manually, and with tools. Test this thoroughly and if you make changes test it again.
• Threat model this or make a security user story about this. It’s a user story/potential threat to almost every app and API on the net. Take it very seriously.
• This OWASP Resource from the Cheat Sheets Project is extremely helpful: OWASP Authentication Cheatsheet

Advice from the OWASP Project team (it is also excellent!)

• Make sure you know all the possible flows to authenticate to the API (mobile/ web/deep links that implement one-click authentication/etc.)
• Ask your engineers what flows you missed.
• Read about your authentication mechanisms. Make sure you understand what and how they are used. OAuth is not authentication, and neither is API keys.
• Don’t reinvent the wheel in authentication, token generation, password storage. Use the standards.
• Credential recovery/forget password endpoints should be treated as login endpoints in terms of brute force, rate limiting, and lockout protections.
• Use the OWASP Authentication Cheatsheet. It’s very good!
• Where possible, implement multi-factor authentication.
• Implement anti brute force mechanisms to mitigate credential stuffing, dictionary attack, and brute force attacks on your authentication endpoints. This mechanism should be stricter than the regular rate limiting mechanism on your API.
• Implement account lockout / captcha mechanism to prevent brute force against specific users. Implement weak-password checks.
• API keys should not be used for user authentication, but for client app/ project authentication.

In the next blog post we will be talking about API3:2019 Excessive Data Exposure!