Hello Everyone, Thank you so much for 1.2k Followers !

This is the Part 05 of the series, in the last part we discussed about Identity role testing.

In this part we are going to learn about Authentication Testing.

Every application needs an authentication mechanism for the users, but sometimes it can be bypassed, in this sections we are going to test this mechanism for any vulnerabilities.

What is Authentication ?

Authentication is among the simplest of all the security mechanisms employed within web applications. In the typical case, a user supplies her username and password, and the application must verify that these items are correct. If so, it lets the user in. If not, it does not. Despite its apparent simplicity, devising a secure authentication function is a subtle business. In real-world web applications authentication often is the weakest link, which enables an attacker to gain unauthorized access.

Lets Begin The Testing

As you know most of websites have a set of rules for settings the password, For Example:

But some websites may not have these rules, or may have weak rules which allows the users to create weak passwords which can be guessed easily by the attacker, granting him or her unauthorized access to the application.

Steps To Test:

1. Review the website for any description of the rules
2. If self-registration is possible, attempt to register to find out the rules.
3. If password change is possible attempt to change your password to various weak values

If the application allows an attacker to make repeated login attempts with different passwords until he guesses the correct one, it is highly vulnerable even to an amateur attacker who manually enters some common usernames and passwords into his browser.

In this situation, any attacker will use automated techniques to attempt to guess passwords, based on lengthy lists of common values. Given today’s bandwidth and processing capabilities, it is possible to make thousands of login attempts per minute from a standard PC and DSL connection.

For Example:

Steps To Test:

1. Manually submit several bad login attempts from your account and look at the error messages
2. After about 10 failed logins, if the application has not returned a message about account lockout, attempt to log in correctly. If this succeeds, there is probably no account lockout policy.
3. If the account locks out try using a different account and this time use a different cookie for each login attempt if the application assigns a cookie
4. If you do not control any accounts, attempt to enumerate a valid username and make several bad logins using this.
5. For performing a brute force attack identify the difference in the responses to successful and failed logins.
6. You can use tools or scripts to perform these attacks like Burpsuite, Owasp Zap.

Example Report:

We are going to use this report: https://hackerone.com/reports/223337

Submitted by,
jaypatel to Weblate on April 24, 2017, 9:26am UTC

A typical login form requires a username and a password. If the login fails one of them is of course incorrect, but if the application tells you which of them is incorrect through an error message, this can be exploited.

For Example:

In this instance, you can use an automated attack to iterate through a large list of common usernames to enumerate which ones are valid. A list of enumerated usernames can be used as the basis for various subsequent attacks, including password guessing, attacks on user data or sessions, or social engineering.

Steps To Test:

1. Create an account, so you will know one correct username, submit one login using your username and wrong password and another login with a random username.
2. Record every detail of the responses of these both, you can use burpsuite comparer to compare both the responses.
3. Try to discover any differences in the responses to the two login attempts.
4. If this doesn’t work try to do the same thing everywhere where a username is required.(for example password change, forgot password)
5. If you find a valid difference, you can use any automated tool and a list of common usernames and filter the responses so that you get the correct usernames.

Example Report:

We are going to use this report: https://hackerone.com/reports/1166054

Submitted by,
mohanad987 to UPchieve on April 15, 2021, 9:54pm UTC

Here the attacker submits a random email in the forgot password feature, then intercepts the request in burpsuite, he gets an error in the response stating “No account with that id found” which can be exploited to find the valid usernames.

Vulnerabilities that are deliberately avoided in the main login function often reappear in the password change function. Many web applications’ password change functions are accessible without authentication and do the following

• Allow unrestricted guesses of the “existing password” fi eld
• Provides error if the username is valid
• check whether the “new password” and “confirm new password” has same value.

Steps To Test:

1. Identify any password change functionality in the application
2. Make various requests to the password change function using invalid usernames, invalid existing passwords, and mismatched “new password” and “confirm new password” values.
3. Try to identify any behavior that can be used for username enumeration or brute-force attacks

Like password change functionality, mechanisms for recovering from a forgotten password situation often introduce problems that may have been avoided in the main login function, such as username enumeration.
A Basic Forgot Password mechanism looks like this:

Steps To Test:

1. Test the account recovery process to ensure that only authorized users can reset passwords.
2. Check for weaknesses in security questions, email verification, or any other means used for account verification.
3. Verify the security of email notifications containing password reset links. Make sure they are sent securely and can’t be intercepted.
4. Test for the expiration of password reset links to prevent attackers from using expired links.
5. Ensure that tokens or links generated for password reset are securely random and not predictable.

Example Report:

We are going to use this report: https://hackerone.com/reports/1175081
Submitted by,
saajanbhujel to UPchieve on April 15, 2021, 9:54pm UTC

Here the users first goes to the reset password features, then enters the victims email address and intercepts the request, then in the request with the victims email also add your own email and then forward this request, now you will receive the password reset link and you can reset the victims password and take control over his account.

That’s it for this blog, Thank you for reading till the end, I hope it helped you in some way.

In the next blog we will learn about Attacking Session Management

If you have any queries free to dm me on instagram:

https://www.instagram.com/om._.arora1603/

Email: [email protected]

Twitter: https://x.com/om83418440

You can also connect with me on linkedin:

https://www.linkedin.com/in/om-arora-b88340213/

Thank you for reading till the end

Please Consider following and liking if you found it helpful.

You can also support me through: