Skip to content

Authentication

Tanner Prynn edited this page Feb 27, 2025 · 21 revisions

Authentication refers to the application's login and logout system, and to verifying that actions are performed by a valid, logged-in user. Authentication controls ensure that all actions are taken by a legitimate user with access to the application. All application functionality should verify that user requests are tied to an active session.

Attempt to login to the application with valid and invalid credentials, observing the results. Incrementally remove or modify cookies and authentication headers to identify which tokens influence the user's access to the application.

Login, Identity, and Account Management

Missing authentication checks

OWASP - A2:2017

Verify that all pages and resources require authentication except those specifically intended to be public. From a development perspective, it is most secure to specifically exclude public pages from authentication middleware rather than applying authentication checks manually to all routes. From an auditing perspective, identify the code pattern used for authentication and systematically check routes where authentication is not required in order to identify missing authentication checks.

Credential handling

Make sure credentials are never sent in plaintext channels. Credentials should only ever be transmitted directly to the relevant party, and not stored or proxied through an intermediate application. Sensitive tokens should not be sent in the URL.

Do not attempt to prevent users from copying and pasting credentials into the application; this behavior discourages usage of secure password managers.

Password hashing

Passwords must be hashed using an appropriate algorithm before being stored. bcrypt is a widely available and secure option (configure for cost 9 or greater). PBKDF2 is no longer recommended. Other options are discussed in Minimum Password Settings by Steve Thomas.

Password strength

When creating or changing user passwords, the application should perform checks for password complexity and reuse of previous credentials. Complexity checks may be performed client side in order to provide immediate user feedback. A tool such as zxcvbn should be used where possible instead of implementing hard requirements on password length or character classes.

Do not require users to regularly update passwords, as this results in weaker passwords overall (see NIST's new password rules – what you need to know from Sophos).

Password reset & account recovery

Assess the security of the account recovery mechanism, focusing on the following major features:

  • Password reset emails should include a link with an unguessable token that expires after a short period of time. Emails and logs should never disclose plaintext passwords, temporary or otherwise.

  • Account recovery functionality cannot be used to bypass other security features such as multi-factor authentication or account lockout.

  • Alternative recovery flows (e.g. answering "security questions") should be discouraged as these flows are less secure than email-based reset in the large majority of cases (see Secrets, Lies, and Account Recovery: Lessons from the Use of Personal Knowledge Questions at Google by Bonneau et al.).

Account management

Account management actions include changing passwords, changing primary or recovery email addresses, and adding or removing multi-factor authentication. All account management functions should:

  • Require that full authentication is performed using existing credentials (password and possible second factor) before performing changes.
  • Send an email to the existing primary email address notifying the user of the change and providing follow-up steps in the case of compromise.

Multi-stage or multi-factor authentication

If the application offers multi-factor authentication, audit the implementation to ensure that no authentication stage can be skipped or bypassed. See Testing Two-Factor Authentication by aschmitz.

Impersonation

If the application allows administrators to impersonate other users, test this functionality for authorization and access control issues.

Single-Sign On

If the application implements a third-party authentication mechanism such as OAuth or SAML, review the implementation for the following issues:

  • Weak or modifiable cryptographic parameters
  • Replay of cryptographic messages
  • Bypass of authentication through token manipulation or third-party impersonation
  • Common issues with implementations of standards (e.g. SAML Signature Wrapping)

Sites making use of OAuth must take extreme care to strictly validate redirect URLs (both in the redirect_uri OAuth parameter and throughout the application), or risk leaking authentication tokens to attacker-controlled sites via uncontrolled redirects. In addition, ensure that CSRF vulnerabilities are prevented via validation of the state parameter; otherwise, an attacker could potentially log in a user to an existing account or link an existing account to an attacker-controlled account on the identity provider, thus gaining access to the victim's data.

For more information, see:

Session Management

Implementation

Determine what session management mechanism is used: framework-provided, application-specific, or external to the application.

For third-party libraries, review known vulnerabilities or implementation issues (for example, see Pragmatic Web Security's JWT Security Cheat Sheet [PDF]).

If the application implements its own session management, check for common issues such as weak cryptographic primitives or unauthenticated ciphertext (see Cryptography).

Session token predictability

Determine if the session management token is meaningful and/or predictable. The simplest, easiest-to-secure session token implementations use an unguessable random value stored in the database. This type of token is called an "opaque" token.

The alternative to opaque tokens is signed cryptographic tokens (e.g. JWT or the default implementation in Rails). Regardless of the token type, an attacker must not be able to guess or forge a token for any other user, or modify their own token to change session attributes.

Session token invalidation

Verify that an account's active sessions are revoked when the user logs out and when the account is deleted, deactivated, or banned.

For most applications, long-lived session tokens are acceptable. Expiring sessions over extremely short periods of time (e.g. one hour or one day) generally does not offer security benefits and instead makes users accustomed to regularly entering credentials, meaning they are less likely to maintain awareness if targeted by a phishing attack.

Session fixation

Check that a new, unguessable session token is generated with each login. If the application uses a user-supplied token when creating a new session, session fixation attacks can occur.

Session token disclosure

Verify that session tokens are never disclosed in URLs, error messages, or logs.

Next Section

Continue to Authorization.

Clone this wiki locally