The OWASP Definition of broken authentication goes very deep and while this is not usually a problem for pentesters as they are required to pretty much report anything and let the customer decide what course of action to take. If we talk about bug bounty hunting though, these vulnerabilties are all useful to us as well, but maybe not immediately.
What OWASP means with broken authentication might differ from the definition most people have in their heads so let's dive a bit deeper into what they actually mean. OWASP is basically talking about bad session management. It seems mostly about invalid session validation. Normally i would think of things like broken access control but these are classified under chapter 5 in their own chapter.
When an attack has a list of passwords and usernames, the attacker might be able to try to them all due to the server permitting automated attacks. This is called credential stuffing and the server should prevent this by enabling captcha's after several failed login attempts.
Permitting of brute forcing or automated scripts is a security flaw and it might not get accepted in bug bounties but as pentesters we do need to report them and classify their severity properly.
We should also never be able to register with weak passwords like "admin/admin" or "Password1". This will make it easier to brute force the password of a lazy employee that did not want to create a proper password.
What can also happen is that our target uses weak password recovery options like knowledge based recovery. This is when the server asks you to set several security questions and answers to them. The problem with this system is that people often set and forget these questions. This allows an attacker to find out that question and simply ask the victim in a nonchallant conversation. If the victim forgot they had a security question asking for the name of their first dog, and attacker can start a conversation about pets and get to know the answer pretty easily.
A good way to solve this password recovery issues is to rely on secondary backup options like a backup email adress or phone number. This would increase the difficulty for the attacker as they would have to hack the secondary email adres or even phone of the victim.
Another fun thing i like to talk about is weak password encryption. Some beginning programmers don't know the sensitivity of a password and how bad it can be if they are leaked as these days people seem to use the same password for everything.
A fun example of this is a website i was testing where i clicked "forgot password", i filled in my email adres and i saw the email come in. The only problem was that they were able to me my password in plain text! Normal hashing can not be reversed easily, which is why most passwords are hashed and salted when entered into a database. If an application does not do this, that is a very bad sign. I would turn around and run as fast as you can. The big problem with this defect is that is really hard to notice. If the application does not treat your password correctly, normally you would never know this as you can not have access to the database.
We can also have a look at multi-factor authentication. If it's missing, as a pentester we can definitly reports this as a best practice. If however it is provided, we have to check if it works correctly. We can see if we can still make requests that require MFA (multi factor authentication) without entering the MFA parameter. We can leave it empty, change it to a random value or even remove the parameter completly. We need to try this on all the requests that require MFA and if any of them still works after messing with the parameter, we have a vulnerability on our hands. It's going to be somewhat lower in severity though since it does require the account under attack to already be compromised.
It can happen at times that companies have two applications and sometimes you log into one and need to switch to the other. There are several ways to handle authentication when it comes to this scenario and the least safe way is to send the session ID as a GET parameter. Under normal situations, this is not going to pose much of a threat as the URL gets encrypted when using HTTPS traffic. However in case of using regular HTTP traffic or if the attacker was able to perform a MiTM (Man in the middle) attack, the account can get compromised in this way. As a pentester we can definitly report this as a best practice again but as bug bounty hunters, this issue will not be accepted due to the requirements of having a MiTM attack.