Skill Level: Beginner

Broken Authentication vulnerability is ranked 2nd and is classified in OWASP as "A2:2017-Broken Authentication" and in CWE referred as "CWE-287: Improper Authentication".


  1. Broken Authentication:

    Broken Authentication vulnerability is ranked 2nd and is classified in OWASP as “A2:2017-Broken Authentication” and in CWE referred as “CWE-287: Improper Authentication“, This vulnerability is related to misconfiguration / incorrect implementation of authentication mechanism in handling authentication and session management.

    The prevalence of broken authentication is widespread due to the design and implementation of most identity and access (IAM) controls. Stateful applications are required to maintain sessions for transactions primarily in the form of Unique Hashes maintained inside session cookie (in case of Web application), API Keys / Bearer token in case of API’s.

    This vulnerability can be detected by using combination of manual techniques & automated techniques.

    General Misconfigurations / Incorrect implementations
    – Application has not implemented limits on failed login attempts, Application has not implemented multi-factor factor authentication, No strong password policy enforced.

                   The above weakness can be exploited by an attacker by using brute force methods, attacker user automated tools along with list of known credentials ie., Dictionary attack ref: https://github.com/danielmiessler/SecLists/tree/master/Passwords

    – Using ineffective credential recovery and forgot-password logics.

                   Attacker will try various manual ways to exploit the business logic of recovering or resetting forgotten password. ie., Guessing the recovery related security questions, manipulating with user name / e-mail ID’s.

    – Using plain-text or weak hashing methods for storing credentials.

                   By any means if attacker gets the dump of credentials and if it is hashed, he will try to crack the hashes using rainbow table method, there will be a greater chance of success if credentials are hashed using weak hashing method.

    – Exposing session ID’s in the URL, Not rotating Session ID’s or using Predictable Session IDs, Session IDs are not invalidated on logout or on long period of inactivity.

                   The session ID’s which are exposed in the URL’s may get recorded in router / gateway / firewall logs, if attacker gets hold of those logs then that information can be further used to predict session ID’s or even to establish any sessions which are still active due to not rotating or invalidating the session ID’s. Attacker uses various methods ie., XSS to steal session ID’s which he may try to reuse if not properly handled.


     – Implement multi-factor authentication to prevent brute force attacks.

    – Enforce password policy, Align password length, complexity and rotation policies with NIST 800-63 B’s guidelines in section 5.1.1 ref: https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret

    – Implement weak-password checks, against a list of the top 10000 worst passwords ref: https://github.com/danielmiessler/SecLists/tree/master/Passwords

    – Harden the Application to respond with generic error messages in case of login failures to avoid account enumeration.

    – Implement delay between subsequent failed login and log all the failures with request origin address.

    – Use a server-side, secure, built-in session manager that generates a new random session ID with high entropy after login. Session IDs should not be in the URL, be securely stored and invalidated after logout, idle, and absolute timeouts. Use well known IAM service.

    – Use strong Hashing with Salt for storing the credentials. ref: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#Use_a_cryptographically_strong_credential-specific_salt


  2. Further Reference:





Join The Discussion