DEV Community

Cover image for API2:2019 - Broken User Authentication
Breno Vit贸rio
Breno Vit贸rio

Posted on • Updated on

API2:2019 - Broken User Authentication

Continuing our series about the OWASP API Security Top 10, this time we are going to talk a little bit about Broken User Authentication. Hope you like it 馃

馃 User Authentication, What is it?

Imagine a login page, which asks you for both your email address and your password.

Login page, asking for email and password

These are some possible interactions you might have with the page, and the expected responses for each interaction:

  • If you click on the login button without passing any data to the input fields, the page returns an error 馃え
  • If you type your email but don't type any password, when you try to login, the page will return an error 馃槫
  • If you type your email and type a wrong password, when you try to login, the page will still return an error 馃が

But if you manage to somehow insert your email along with your correct password, this is what you will get as a response from the application:

Page saying: hello user1337

This process of picking up your email and password in order to verify that you are User1337 is a possible form of authentication. In more general terms, any sort of process which verifies whether or not users are who they're saying they are, may be called an user authentication method.

User authentication comes in different shapes, colours and flavours. You can find it not only in basic login forms, but also in password reset forms, HTTP request headers/cookies, 2FA apps, and the list goes on and on...

馃敁 How Does it Get Broken?

So how does API2:2019 happen? Well, the Broken User Authentication happens when a faulty implementation of an authentication mechanism allows an attacker to impersonate someone else, temporarily or permanently.

馃 Example 1

An application in which all passwords have 4 numeric digits and has no brute forcing prevention methods at all. In this scenario, anyone with a computer might impersonate any user of the application in a few seconds or minutes just by automating the process of attempting 4 digit number combinations. So we have a Broken User Authentication here 馃槻

馃く Example 2

A password reset flow for users who forgot their password. The user enters their email address in order to receive a link for setting a new password:

Password reset form, asking for a new password

When the user submit this form, the following HTTP request is sent:

POST /password-reset/n1c3-t0k3n-h3r3 HTTP/1.1
Content-Type: application/json

聽聽聽聽"password": "therealpassword123",
聽聽聽聽"passwordConfirm": "therealpassword123",
聽聽聽聽"userID": 1337

Notice that there's an attribute called userID which apparently refers to the ID of the user who did request this password change. And remember, from the last post, that there is something called Broken Object Level Authorization, which is very very common in applications these days.

If this particular endpoint is vulnerable to API1:2019, in a way that by changing the value of userID an attacker end up changing the password of someone else and being able to impersonate them, we may say that this same endpoint is also vulnerable to API2:2019, because we have a broken authorization mechanism leading to a broken authentication mechanism. 馃槶

馃摎 External materials

As my goal with this series is to just explain what each flaw is, I would like to suggest some materials about authentication security issues, so you understand better the details of it:

Thank you for taking your time 馃

Discussion (0)