OWASP · manindar-mohan · Jul 3, 2022 · Jul 3, 2022 · Jul 13, 2022 · Aug 6, 2022
diff --git a/...ion_Testing/01-Testing_for_Credentials_Transported_over_an_Encrypted_Channel.md b/...ion_Testing/01-Testing_for_Credentials_Transported_over_an_Encrypted_Channel.md
diff --git a/...ing/02-Testing_for_Default_Credentials.md → ...ing/01-Testing_for_Default_Credentials.md b/...ing/02-Testing_for_Default_Credentials.md → ...ing/01-Testing_for_Default_Credentials.md
@@ -2,7 +2,7 @@
 
 |ID          |
 |------------|
-|WSTG-ATHN-02|
+|WSTG-ATHN-01|
 
 ## Summary
 

diff --git a/...03-Testing_for_Weak_Lock_Out_Mechanism.md → ...02-Testing_for_Weak_Lock_Out_Mechanism.md b/...03-Testing_for_Weak_Lock_Out_Mechanism.md → ...02-Testing_for_Weak_Lock_Out_Mechanism.md
@@ -2,7 +2,7 @@
 
 |ID          |
 |------------|
-|WSTG-ATHN-03|
+|WSTG-ATHN-02|
 
 ## Summary
 

diff --git a/...ng_for_Bypassing_Authentication_Schema.md → ...ng_for_Bypassing_Authentication_Schema.md b/...ng_for_Bypassing_Authentication_Schema.md → ...ng_for_Bypassing_Authentication_Schema.md
@@ -2,7 +2,7 @@
 
 |ID          |
 |------------|
-|WSTG-ATHN-04|
+|WSTG-ATHN-03|
 
 ## Summary
 
@@ -43,7 +43,7 @@ If a web application implements access control only on the log in page, the auth
 Another problem related to authentication design is when the application verifies a successful log in on the basis of a fixed value parameters. A user could modify these parameters to gain access to the protected areas without providing valid credentials. In the example below, the "authenticated" parameter is changed to a value of "yes", which allows the user to gain access. In this example, the parameter is in the URL, but a proxy could also be used to modify the parameter, especially when the parameters are sent as form elements in a POST request or when the parameters are stored in a cookie.
 
 ```html
-https://www.site.com/page.asp?authenticated=no
+http://www.site.com/page.asp?authenticated=no
 
 raven@blackbox /home $nc www.site.com 80
 GET /page.asp?authenticated=yes HTTP/1.0
@@ -121,14 +121,13 @@ a:2:{s:11:"autologinid";b:1;s:6:"userid";s:1:"2";}  // original value: a:2:{s:11
 Let's disassemble what we did in this string:
 
 1. `autologinid` is now a boolean set to `true`: this can be seen by replacing the MD5 value of the password hash (`s:32:"8b8e9715d12e4ca12c4c3eb4865aaf6a"`) with `b:1`
-2. `userid` is now set to the admin id: this can be seen in the last piece of the string, where we replaced our regular user ID (`s:4:"1337"`) with `s:1:"2"`
+2. `userid` is now set to the admin ID: this can be seen in the last piece of the string, where we replaced our regular user ID (`s:4:"1337"`) with `s:1:"2"`
 
 ## Tools
 
 - [WebGoat](https://owasp.org/www-project-webgoat/)
-- [Zed Attack Proxy (ZAP)](https://www.zaproxy.org)
+- [OWASP Zed Attack Proxy (ZAP)](https://www.zaproxy.org)
 
 ## References
 
 - [Niels Teusink: phpBB 2.0.12 authentication bypass](http://blog.teusink.net/2008/12/classic-bug-phpbb-2012-authentication.html)
-- [David Endler: "Session ID Brute Force Exploitation and Prediction"](https://www.cgisecurity.com/lib/SessionIDs.pdf)
diff --git a/...sting_for_Vulnerable_Remember_Password.md → ...sting_for_Vulnerable_Remember_Password.md b/...sting_for_Vulnerable_Remember_Password.md → ...sting_for_Vulnerable_Remember_Password.md
@@ -2,7 +2,7 @@
 
 |ID          |
 |------------|
-|WSTG-ATHN-05|
+|WSTG-ATHN-04|
 
 ## Summary
 

diff --git a/...6-Testing_for_Browser_Cache_Weaknesses.md → ...5-Testing_for_Browser_Cache_Weaknesses.md b/...6-Testing_for_Browser_Cache_Weaknesses.md → ...5-Testing_for_Browser_Cache_Weaknesses.md
@@ -2,7 +2,7 @@
 
 |ID          |
 |------------|
-|WSTG-ATHN-06|
+|WSTG-ATHN-05|
 
 ## Summary
 

diff --git a/...curity_Testing/04-Authentication_Testing/06-Testing_for_Weak_Password_Policy.md b/...curity_Testing/04-Authentication_Testing/06-Testing_for_Weak_Password_Policy.md
@@ -0,0 +1,36 @@
+# Testing for Weak Authentication Methods
+
+|ID          |
+|------------|
+|WSTG-ATHN-06|
+
+## Summary
+
+The most prevalent and most easily administered authentication mechanism is a static password. The password represents the keys to the kingdom, but is often subverted by users in the name of usability. In each of the recent high profile hacks that have revealed user credentials, it is lamented that most common passwords are still: `123456`, `password` and `qwerty`.
+
+Additionally, applications may utilize alternative credentials that are treated the same as a password, but are considerably weaker, such as a birthdates, social security numbers, PINs, or security questions. In some scenarios, these more easily guessed credentials may act as the only user supplied value for authentication.
+
+## Test Objectives
+
+- Determine the resistance of the application against brute force password guessing using available password dictionaries by evaluating the length, complexity, reuse, and aging requirements of passwords.
+
+## How to Test
+
+1. What characters are permitted and forbidden for use within a password? Is the user required to use characters from different character sets such as lower and uppercase letters, digits and special symbols?
+2. How often can a user change their password? How quickly can a user change their password after a previous change? Users may bypass password history requirements by changing their password 5 times in a row so that after the last password change they have configured their initial password again.
+3. When must a user change their password?
+    - Both [NIST](https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver) and [NCSC](https://www.ncsc.gov.uk/collection/passwords/updating-your-approach#PasswordGuidance:UpdatingYourApproach-Don'tenforceregularpasswordexpiry) recommend **against** forcing regular password expiry, although it may be required by standards such as PCI DSS.
+4. How often can a user reuse a password? Does the application maintain a history of the user's previous used 8 passwords?
+5. How different must the next password be from the last password?
+6. Is the user prevented from using his username or other account information (such as first or last name) in the password?
+7. What are the minimum and maximum password lengths that can be set, and are they appropriate for the sensitivity of the account and application?
+8. Is it possible to set common passwords such as `Password1` or `123456`?
+9. Is the credential chosen for the user by the application, such as a social security number or a birthdate? Is the credential that's utilized in lieu of a standard password easily obtainable, predictable, or susceptible to brute-force attacks?
+
+## Remediation
+
+To mitigate the risk of easily guessed passwords facilitating unauthorized access there are two solutions: introduce additional authentication controls (i.e. two-factor authentication) or introduce a strong password policy. The simplest and cheapest of these is the introduction of a strong password policy that ensures password length, complexity, reuse and aging; although ideally both of them should be implemented.
+
+## References
+
+- [Brute Force Attacks](https://owasp.org/www-community/attacks/Brute_force_attack)
diff --git a/...Testing/04-Authentication_Testing/07-Testing_for_Weak_Authentication_Methods.md b/...Testing/04-Authentication_Testing/07-Testing_for_Weak_Authentication_Methods.md
@@ -2,7 +2,7 @@
 
 |ID          |
 |------------|
-|WSTG-ATHN-07|
+|WSTG-ATHN-06|
 
 ## Summary
 

diff --git a/...ting_for_Weak_Security_Question_Answer.md → ...ting_for_Weak_Security_Question_Answer.md b/...ting_for_Weak_Security_Question_Answer.md → ...ting_for_Weak_Security_Question_Answer.md
@@ -2,11 +2,11 @@
 
 |ID          |
 |------------|
-|WSTG-ATHN-08|
+|WSTG-ATHN-07|
 
 ## Summary
 
-Often called "secret" questions and answers, security questions and answers are often used to recover forgotten passwords (see [Testing for weak password change or reset functionalities](09-Testing_for_Weak_Password_Change_or_Reset_Functionalities.md), or as extra security on top of the password.
+Often called "secret" questions and answers, security questions and answers are often used to recover forgotten passwords (see [Testing for weak password change or reset functionalities](08-Testing_for_Weak_Password_Change_or_Reset_Functionalities.md), or as extra security on top of the password.
 
 They are typically generated upon account creation and require the user to select from some pre-generated questions and supply an appropriate answer. They may allow the user to generate their own question and answer pairs. Both methods are prone to insecurities. Ideally, security questions should generate answers that are only known by the user, and not guessable or discoverable by anybody else. This is harder than it sounds.
 Security questions and answers rely on the secrecy of the answer. Questions and answers should be chosen so that the answers are only known by the account holder. However, although a lot of answers may not be publicly known, most of the questions that sites implement promote answers that are pseudo-private.
@@ -45,7 +45,7 @@ Try to create security questions by creating a new account or by configuring you
 
 ### Testing for Brute-forcible Answers
 
-Use the methods described in [Testing for Weak lock out mechanism](03-Testing_for_Weak_Lock_Out_Mechanism.md) to determine if a number of incorrectly supplied security answers trigger a lockout mechanism.
+Use the methods described in [Testing for Weak lock out mechanism](02-Testing_for_Weak_Lock_Out_Mechanism.md) to determine if a number of incorrectly supplied security answers trigger a lockout mechanism.
 
 The first thing to take into consideration when trying to exploit security questions is the number of questions that need to be answered. The majority of applications only need the user to answer a single question, whereas some critical applications may require the user to answer two or even more questions.
 

diff --git a/...ssword_Change_or_Reset_Functionalities.md → ...ssword_Change_or_Reset_Functionalities.md b/...ssword_Change_or_Reset_Functionalities.md → ...ssword_Change_or_Reset_Functionalities.md
@@ -2,11 +2,11 @@
 
 |ID          |
 |------------|
-|WSTG-ATHN-09|
+|WSTG-ATHN-08|
 
 ## Summary
 
-For any application that requires the user to authenticate with a password, there must be a mechanism by which the user can regain access to their account if they forget their password. Although this can sometimes be a manual process that involves contacting the owner of the website or a support team, users are frequently allowed to carry out a self-service password reset, and to regain access to their account by providing some other evidence of their identity.
+For any application that requires the user to authenticate with a password, there must be a mechanism by which the user can regain access to their account if they forget their password. Although this can sometimes be a manual process that involves contacting the owner of the site or a support team, users are frequently allowed to carry out a self-service password reset, and to regain access to their account by providing some other evidence of their identity.
 
 As this functionality provides a direct route to compromise the user's account, it is crucial that it is implemented securely.
 
@@ -107,7 +107,7 @@ In this model, the user is emailed a link that contains a token. They can then c
 
 - Can you inject a different host header?
 
-  If the application trusts the value of the `Host` header and uses this to generate the password reset link, it may be possible to steal tokens by injecting a modified `Host` header into the request. See the [Testing for Host Header Injection](../07-Input_Validation_Testing/17-Testing_for_Host_Header_Injection.md) guide for further information.
+  If the application trusts the value of the `Host` header and uses this to generate the password reset link, it may be possible to steal tokens by injecting a modified `Host` header into the request. See the [Testing for Host Header Injection](../07-Input_Validation_Testing/16-Testing_for_Host_Header_Injection.md) guide for further information.
 
 - Is the link exposed to third parties?
 
@@ -147,7 +147,7 @@ Rather than sending a token in an email, an alternative approach is to send it v
 
   Sending an SMS or triggering an automated phone call to a user is significantly more disruptive than sending an email, and could be used to harass a user, or even carry out a denial of service attack against their phone. The application should implement rate limiting to prevent this.
 
-  Additionally, SMS messages and phone calls often incur financial costs for the sending party. If an attacker is able to cause a large number of messages to be sent, this could result in significant costs for the website operator. This is especially true if they are sent to international or premium rate numbers. However, allowing international numbers may be a requirement of the application.
+  Additionally, SMS messages and phone calls often incur financial costs for the sending party. If an attacker is able to cause a large number of messages to be sent, this could result in significant costs for the site operator. This is especially true if they are sent to international or premium rate numbers. However, allowing international numbers may be a requirement of the application.
 
 - Is SMS or a phone call considered sufficiently secure?
 
@@ -161,7 +161,7 @@ Rather than sending a token in an email, an alternative approach is to send it v
 
 Rather than sending them a link or new password, security questions can be used as a mechanism to authenticate the user. This is considered to be a weak approach, and should not be used if better options are available.
 
-See the [Testing for Weak Security Questions](08-Testing_for_Weak_Security_Question_Answer.md) guide for further information.
+See the [Testing for Weak Security Questions](07-Testing_for_Weak_Security_Question_Answer.md) guide for further information.
 
 ### Authenticated Identity and Configuration Changes