# 4.4 Authentication Testing

## [Authentication Testing](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/04-Authentication_Testing/README)

## 4.4.1 [Testing for Credentials Transported over an Encrypted Channel](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/04-Authentication_Testing/01-Testing_for_Credentials_Transported_over_an_Encrypted_Channel)

* [ ] Check that the credentials always travel over encrypted channels.
* [ ] If the server returns cookie information for a session token, the cookie should also include the `Secure` attribute to avoid the client exposing the cookie over unencrypted channels later. Look for the `Secure` keyword in the response header.

**Evidence**:

```
​
```

## 4.4.2 [Testing for Default Credentials](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/04-Authentication_Testing/02-Testing_for_Default_Credentials)

* [ ] Enumerate the applications for default credentials (username & password) and validate if they still exist.
  * [Cirt - Default passwords](https://cirt.net/passwords)
  * [SectLists - Default Credentials](https://github.com/danielmiessler/SecLists/tree/master/Passwords/Default-Credentials)
  * [Passwords Database](https://www.passwordsdatabase.com/)
  * [Data Recovery - Default Passwords](https://datarecovery.com/rd/default-passwords/)
  * [DefaultCreds Cheat Sheet](https://github.com/ihebski/DefaultCreds-cheat-sheet)
  * [Small Test](https://github.com/danielmiessler/SecLists/blob/master/Passwords/Common-Credentials/top-20-common-SSH-passwords.txt)

> You can use Burp's Cluster Bomb attack

* [ ] Review and assess new user accounts and if they are created with any defaults or identifiable patterns.

**Evidence**:

```
​
```

## 4.4.3 [Testing for Weak Lock Out Mechanism](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/04-Authentication_Testing/03-Testing_for_Weak_Lock_Out_Mechanism)

* [ ] Evaluate the account lockout mechanism’s ability to mitigate brute force password guessing.
  * [ ] Attempt to log in with an incorrect password X times. Then, log in with the correct password. If successful increase X +1. Try this 10 times until the account is locked out, if the account is not locked out, it might not have Lock Out mechanisms.
  * [ ] If the account is locked out, try to access with the correct credentials in intervals of 2 minutes after the first minute, trying to obtain if the account is automatically unlocked after a period of time.
* [ ] CAPTCHA effectiveness
  * [ ] Assess CAPTCHA challenges and attempt automating solutions depending on difficulty.
  * [ ] Attempt to submit request without solving CAPTCHA via the normal UI mechanism(s).
  * [ ] Attempt to submit request with intentional CAPTCHA challenge failure.
  * [ ] Attempt to submit request without solving CAPTCHA (assuming some default values may be passed by client-side code, etc) while using a testing proxy (request submitted directly server-side).
  * [ ] Attempt to fuzz CAPTCHA data entry points (if present) with common injection payloads or special characters sequences.
  * [ ] Check if the solution to the CAPTCHA might be the alt-text of the image(s), filename(s), or a value in an associated hidden field.
  * [ ] Attempt to re-submit previously identified known good responses.
  * [ ] Check if clearing cookies causes the CAPTCHA to be bypassed (for example if the CAPTCHA is only shown after a number of failures).
  * [ ] If the CAPTCHA is part of a multi-step process, attempt to simply access or complete a step beyond the CAPTCHA (for example if CAPTCHA is the first step in a login process, try simply submitting the second step \[username and password]).
  * [ ] Check for alternative methods that might not have CAPTCHA enforced, such as an API endpoint meant to facilitate mobile app access.
* [ ] Evaluate the unlock mechanism’s resistance to unauthorized account unlocking.
  * [ ] Typical unlock mechanisms may involve secret questions or an emailed unlock link. The unlock link should be a unique one-time link, to stop an attacker from guessing or replaying the link and performing brute force attacks in batches Note that an unlock mechanism should only be used for unlocking accounts. It is not the same as a password recovery mechanism, yet could follow the same security practices.

**Evidence**:

```
​
```

## 4.4.4 [Testing for Bypassing Authentication Schema](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/04-Authentication_Testing/04-Testing_for_Bypassing_Authentication_Schema)

Try to break the authentication process in order to obtain a valid session ID.

* [ ] Manipulate the server's response
* [ ] Exploit the "remember me" functionality

Try to bypass the authentication mechanisms in any section of the web pages which requires some sort of authentication with the following techinques:

* [ ] Access the URL directly without any setted Cookie. You can use the [Autorize](https://portswigger.net/bappstore/f9bbac8c4acf4aefa4d7dc92a991af2f) Burp plugin with empty cookies.
* [ ] Check if the URL or POST parameters are used to verify a successful log in. E.x. `http://www.site.com/page.asp?authenticated=no`.
* [ ] Check if session IDs generation are predictable. Use Burp Suite sequencer.
* [ ] Tests if the authentication function works as intended and it is not bypasseable
  * [ ] Perform SQL or NoSQL injection attacks. →[SQLi\_Auth\_Bypass-Master\_List.txt](https://github.com/Marmeus/Kali-Booster/blob/main/Assets/Wordlists/SQLi_Auth_Bypass-Master_List.txt) & [No SQLI Payloads](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/NoSQL%20Injection)

**Evidence**:

```
​
```

## 4.4.5 [Testing for Vulnerable Remember Password](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/04-Authentication_Testing/05-Testing_for_Vulnerable_Remember_Password)

* [ ] Validate that the generated session is managed securely and do not put the user’s credentials in danger.
* [ ] Check if credentials are stored on the browser memory.

**Evidence**:

```
​
```

## 4.4.6 [Testing for Browser Cache Weaknesses](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/04-Authentication_Testing/06-Testing_for_Browser_Cache_Weaknesses)

* [ ] Review if the application stores sensitive information on the client-side.
* [ ] Review if access can occur without authorization.
* [ ] Entering sensitive information into the application and logging out. Then the tester clicks the Back button of the browser to check whether previously displayed sensitive information can be accessed whilst unauthenticated.
* [ ] Check that the following directives are present:

```bash
Cache-Control: no-cache, no-store
Expires: 0
Pragma: no-cache
```

**Evidence**:

```
​
```

## 4.4.7 [Testing for Weak Password Policy](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/04-Authentication_Testing/07-Testing_for_Weak_Password_Policy)

* [ ] Evaluate the length and complexity
* [ ] Evaluate the existence of a password history.
* [ ] Check if the user can request password recovery on demand without restrictions.

**Evidence**

```
​
```

## 4.4.8 [Testing for Weak Security Question Answer](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/04-Authentication_Testing/08-Testing_for_Weak_Security_Question_Answer)

* [ ] Determine the complexity and how straight-forward the questions are.
* [ ] Assess possible user answers and brute force capabilities.

**Evidence**:

```
​
```

## 4.4.9 [Testing for Weak Password Change or Reset Functionalities](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/04-Authentication_Testing/09-Testing_for_Weak_Password_Change_or_Reset_Functionalities)

* [ ] if users, other than administrators, can change or reset passwords for accounts other than their own?
* [ ] if users can manipulate or subvert the password change or reset process to change or reset the password of another user or administrator?
* [ ] if the password change or reset process is vulnerable to CSRF?
* [ ] Is the old password requested to complete the change?
* [ ] Are reset passwords generated randomly?

**Evidence**:

```
​
```

## 4.4.10 [Testing for Weaker Authentication in Alternative Channel](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/04-Authentication_Testing/10-Testing_for_Weaker_Authentication_in_Alternative_Channel)

* [ ] Identify alternative authentication channels (SSO).
* [ ] For each alternative channel where user accounts or functionality are shared, identify if all the authentication functions of the primary channel are available, and if anything extra exists.
* [ ] Assess the security measures used and if any bypasses exists on the alternative channels.

**Evidence**:

```
​
```