> For the complete documentation index, see [llms.txt](https://0xhunterr.gitbook.io/the-nen-book/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://0xhunterr.gitbook.io/the-nen-book/web_appsec/authentication_vulnerabilities.md). # Authentication\_Vulnerabilities ### Testing Methodology #### Weak Password Complexity Requirements * Review the website for any description of the rules. * If self registration is possible, attempt to register several accounts with different kinds of weak passwords to discover what rules are in place. * Very short or blank. * Common dictionary words or names. * Password is the same as the username. * If you control a single account and password change is possible, attempt to change the password to various weak values #### Improper Restriction of Authentication Attempts * Manually submit several bad login attempts for an account you control. * After 10 failed login attempts, if the application does not return a message about account lockout, attempt to log in correctly. If it works, then there is no lockout mechanism. * Run a brute force attack to enumerate the valid password. Tools: Hydra, Burp Intruder, etc. * if the account is locked out, monitor the requests and responses to determine if the lockout mechanism is insecure. Improper Restriction of Authentication Attempts NOTE: Apply this test on all authentication pages #### Verbose Error Message * Perform a successful login while monitoring all traffic in both directions between the client and server * Look for instances where credentials are submitted in a URL query string or as a cookie, or are transmitted back from the server to the client. * Attempt to access the application over HTTP and if there are any redirections to HTTPS #### Insecure Forgot Password Functionality * Identify if the application has any forgotten password functionality * If it does, perform a complete walk-through of the forgot password functionality using an account you have control of while intercepting the requests / responses in a proxy * Review the functionality to determine if it allows for username enumeration or bruteforce attacks * If the application generates an email containing a recovery URL, obtain a number of these URLs and attempt to identify any predictable patterns or sensitive information included in the URL. Also check if the URL is long lived and does not expire #### Defects in Multistage Login Mechanism * Identify if the application uses a multistage login mechanism. * If it does, perform a complete walk-through using an account you have control of while intercepting the requests / responses in a proxy * Review the functionality to determine if it allows for username enumeration or bruteforce attacks. ### Bypasses * Try `X-Forward-For: 127.0.0.1` and change the IP every time you got blocked * Try to log-in to your own account successfully In some implementations, the counter for the number of failed attempts resets if the IP owner logs in successfully ## Something to know * User rate limiting is sometimes preferred to account locking due to being less prone to username enumeration and denial of service attacks, However, it is still not completely secure * HTTP basic authentication `Authorization: Basic base64(username:password)` * often don't support brute-force protection. As the token consists exclusively of static values, this can leave it vulnerable to being brute-forced. * vulnerable to session-related exploits, notably [CSRF](https://portswigger.net/web-security/csrf), against which it offers no protection on its own. ## References * [Rana Khalil Web Security Academy](https://www.youtube.com/watch?v=mox6DL4zK7I\&list=PLuyTk2_mYISJmmOLYzGxVSwS5vAhBVphr\&index=1) * [PortsWigger](https://portswigger.net/web-security/authentication) * [WSTG - v4.2](https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/04-Authentication_Testing/) * \[OWASP ASVS V2 Authentication Verification Requirements]\( en.pdf)