September 26, 2021

A2-Broken Authentication

Attackers have access to bazillions of valid username & password combos for credential stuffing attacks. Everyone can google the default administrative account for every device on the planet and still people don’t always change them. Session management attacks are well understood, particularly in relation to unexpired session tokens.

Broken authentication is widespread due to poor implementation of most identity and access management. Session management is at the heart of authentication and access controls, and is present in all stateful applications.

Attackers can detect broken authentication using manual means and exploit them using automated tools with password lists and dictionary attacks.


Confirmation of the user’s identity, authentication, and session management are critical to protect against authentication-related attacks. There may be authentication weaknesses if the application:

  • Permits automated attacks such as credential stuffing, where the attacker has a list of valid usernames and passwords.
  • Permits brute force or other automated attacks.
  • Permits default, weak, or well-known passwords, such as “Password1” or “admin/admin“.
  • Uses weak or ineffective credential recovery and forgot-password processes, such as “knowledge-based answers”, which cannot be made safe.
  • Uses plain text, encrypted, or weakly hashed passwords (see A3:2017-Sensitive Data Exposure).
  • Has missing or ineffective multi-factor authentication.
  • Exposes Session IDs in the URL (e.g., URL rewriting).
  • Does not rotate Session IDs after successful login.
  • Does not properly invalidate Session IDs. User sessions or authentication tokens (particularly single sign-on (SSO) tokens) aren’t properly invalidated during logout or a period of inactivity.


  • Multi-Factor Auth (MFA)
  • ∆ default passwords.
  • 14 character password minimum.
  • Allow all available character sets (UPPER, lower, $!@#)
  • UID wrong and PWD wrong uses the same message.
  • Limit or increasingly delay failed login attempts. Log all failures and alert administrators when credential stuffing, brute force, or other attacks are detected.
  • 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.

Session Management Checklist

  1. Use the server or framework’s session management controls. The application should only recognize these session identifiers as valid
  2. Session identifier creation must always be done on a trusted system (e.g., The server)
  3. Session management controls should use well vetted algorithms that ensure sufficiently random session identifiers
  4. Set the domain and path for cookies containing authenticated session identifiers to an appropriately restricted value for the site
  5. Logout functionality should fully terminate the associated session or connection
  6. Logout functionality should be available from all pages protected by authorization
  7. Establish a session inactivity timeout that is as short as possible, based on balancing risk and business functional requirements. In most cases it should be no more than several hours
  8. Disallow persistent logins and enforce periodic session terminations, even when the session is active. Especially for applications supporting rich network connections or connecting to critical systems. Termination times should support business requirements and the user should receive sufficient notification to mitigate negative impacts
  9. If a session was established before login, close that session and establish a new session after a successful login
  10. Generate a new session identifier on any re-authentication
  11. Do not allow concurrent logins with the same user ID
  12. Do not expose session identifiers in URLs, error messages or logs. Session identifiers should only be located in the HTTP cookie header. For example, do not pass session identifiers as GET parameters
  13. Protect server side session data from unauthorized access, by other users of the server, by implementing appropriate access controls on the server
  14. Generate a new session identifier and deactivate the old one periodically. (This can mitigate certain session hijacking scenarios where the original identifier was compromised)
  15. Generate a new session identifier if the connection security changes from HTTP to HTTPS, as can occur during authentication. Within an application, it is recommended to consistently utilize HTTPS rather than switching between HTTP to HTTPS.
  16. Supplement standard session management for sensitive server-side operations, like account management, by utilizing per-session strong random tokens or parameters. This method can be used to prevent Cross Site Request Forgery attacks.
  17. Supplement standard session management for highly sensitive or critical operations by utilizing per request, as opposed to per-session, strong random tokens or parameters
  18. Set the “secure” attribute for cookies transmitted over an TLS connection
  19. Set cookies with the HttpOnly attribute, unless you specifically require client-side scripts within your application to read or set a cookie’s value