Introduction

API2:2019 Broken User Authentication

What is Broken User Authentication?

Broken User Authentication can manifest in several issues. Whenever we come across an API endpoint that handles authentication we need to be extra careful since these endpoints will often determine how a user can flow through the application and what data they see. Whenever one of the following conditions is true, we can speak of a "Broken User Authentication".

• If your API allows for credential stuffing. This is an attack where a hacker will try to brute force credentials by using a list with known account names and passwords from other websites. This works because people often re-use their old usernames and passwords so if their credentials leak one time, a lot of accounts are vulnerable. Attackers will take these old credentials and try them on our API endpoints rapidly to see if any of the accounts work on our application. One way to address this is by implementing rate limiting controls or throttling.
• If the API endpoint does not verify the request with a CAPTCHA when needed.
• When the application allows for weak passwords. The best policy is to use a passphrase instead of a password but anything is better than a weak password.
• When the endpoint uses GET parameters (parameters in the URL) to send sensitive data such as passwords or tokens. This could allow for a MiTM attack or exposure on shared systems (school, libraries, etc).
• When our endpoint issues a token such as JWT but does not validate it.
• When we use JWT, we should be aware that we should not accept unsigned or weakly signed tokens.
• When the endpoint does not validate the expiration date of authentication tokens such as session tokens or JWT.
• When the endpoint does not encrypt or hash the password or uses weak encryption algorithms.
• When it uses weak encryption keys that are easy to guess (like a birthday) or easy to crack (like md5).

Example Attack Scenarios

password recovery

The attacker might start the workflow to reset a password by triggering the /api/v1/reset-password endpoint.

POST /api/v1/reset-password
{
	userID=123
}

This will trigger a password reset for a user with the id of 123 and the user will receive a password reset token in their mailbox which is a 4 digit number. Since there is no rate limiting on the endpoint, the attacker can try to send all 4 digit numbers in rapid succession and simply brute force it.