PantsirПанцирь
Cheatsheet

Authentication

Source: OWASP Cheat Sheet Series

Introduction

Authentication (AuthN) is the process of verifying that an individual, entity, or website is who or what it claims to be by determining the validity of one or more authenticators (like passwords, fingerprints, or security tokens) that are used to back up this claim.

Digital Identity is the unique representation of a subject engaged in an online transaction. A digital identity is always unique in the context of a digital service but does not necessarily need to be traceable back to a specific real-life subject.

Identity Proofing establishes that a subject is actually who they claim to be. This concept is related to KYC concepts and it aims to bind a digital identity with a real person.

Session Management is a process by which a server maintains the state of an entity interacting with it. This is required for a server to remember how to react to subsequent requests throughout a transaction. Sessions are maintained on the server by a session identifier which can be passed back and forth between the client and server when transmitting and receiving requests. Sessions should be unique per user and computationally very difficult to predict. The Session Management Cheat Sheet contains further guidance on the best practices in this area.

Authentication General Guidelines

User IDs

The primary function of a User ID is to uniquely identify a user within a system. Ideally, User IDs should be randomly generated to prevent the creation of predictable or sequential IDs, which could pose a security risk, especially in systems where User IDs might be exposed or inferred from external sources.

Usernames

Usernames are easy-to-remember identifiers chosen by the user and used for identifying themselves when logging into a system or service. The terms User ID and username might be used interchangeably if the username chosen by the user also serves as their unique identifier within the system.

Users should be permitted to use their email address as a username, provided the email is verified during sign-up. Additionally, they should have the option to choose a username other than an email address. For information on validating email addresses, please visit the input validation cheat sheet email discussion.

Authentication Solution and Sensitive Accounts

  • Do NOT allow login with sensitive accounts (i.e. accounts that can be used internally within the solution such as to a backend / middleware / database) to any front-end user interface
  • Do NOT use the same authentication solution (e.g. IDP / AD) used internally for unsecured access (e.g., public access / DMZ)

Implement Proper Password Strength Controls

A key concern when using passwords for authentication is password strength. A "strong" password policy makes it difficult or even improbable for one to guess the password through either manual or automated means. The following characteristics define a strong password:

  • Password Length
    • Minimum length for passwords should be enforced by the application.
      • If MFA is enabled passwords shorter than 8 characters are considered to be weak (NIST SP800-63B).
      • If MFA is not enabled passwords shorter than 15 characters are considered to be weak (NIST SP800-63B).
    • Maximum password length should be at least 64 characters to allow passphrases (NIST SP800-63B). Note that certain implementations of hashing algorithms may cause long password denial of service.
  • Do not silently truncate passwords. The Password Storage Cheat Sheet provides further guidance on how to handle passwords that are longer than the maximum length.
  • Allow usage of all characters including unicode and whitespace. There should be no password composition rules limiting the type of characters permitted. There should be no requirement for upper or lower case or numbers or special characters.
  • Ensure credential rotation when a password leak occurs, at the time of compromise identification or when authenticator technology changes. Avoid requiring periodic password changes; instead, encourage users to pick strong passwords and enable Multifactor Authentication Cheat Sheet (MFA). According to NIST guidelines, verifiers should not mandate arbitrary password changes (e.g., periodically).
  • Include a password strength meter to help users create a more complex password
    • zxcvbn-ts library can be used for this purpose.
    • Other language implementations of zxcvbn listed here; however check the age and maturity of each example before use.
  • Block common and previously breached passwords
    • Pwned Passwords is a service where passwords can be checked against previously breached passwords. Details on the API are here.
    • Alternatively, you can download the Pwned Passwords database using this mechanism to host it yourself.
    • Other top password lists are available but there is no guarantee as to how updated they are:
      • Various password lists hosted by SecLists from Daniel Miessler.
      • Static copy of the top 100,000 passwords from "Have I Been Pwned" hosted by NCSC in text and JSON format.

For more detailed information check

Implement Secure Password Recovery Mechanism

It is common for an application to have a mechanism that provides a means for a user to gain access to their account in the event they forget their password. Please see Forgot Password Cheat Sheet for details on this feature.

Store Passwords in a Secure Fashion

It is critical for an application to store a password using the right cryptographic technique. Please see Password Storage Cheat Sheet for details on this feature.

Compare Password Hashes Using Safe Functions

Where possible, the user-supplied password should be compared to the stored password hash using a secure password comparison function provided by the language or framework, such as the password_verify() function in PHP. Where this is not possible, ensure that the comparison function:

  • Has a maximum input length, to protect against denial of service attacks with very long inputs.
  • Explicitly sets the type of both variables, to protect against type confusion attacks such as Magic Hashes in PHP.
  • Returns in constant time, to protect against timing attacks.

Change Password Feature

When developing a change password feature, ensure to have:

  • The user is authenticated with an active session.
  • Current password verification. This is to ensure that it's the legitimate user who is changing the password. Consider this abuse case: a user logs in on a public computer and forgets to log out. Another person could then use that active session. If we don't verify the current password, this other person may be able to change the password.

Transmit Passwords Only Over TLS or Other Strong Transport

See: Transport Layer Security Cheat Sheet

The login page and all subsequent authenticated pages must be exclusively accessed over TLS or other strong transport. Failure to utilize TLS or other strong transport for the login page allows an attacker to modify the login form action, causing the user's credentials to be posted to an arbitrary location. Failure to utilize TLS or other strong transport for authenticated pages after login enables an attacker to view the unencrypted session ID and compromise the user's authenticated session.

Require Re-authentication for Sensitive Features

In order to mitigate CSRF and session hijacking, it's important to require the current credentials for an account before updating sensitive account information such as the user's password or email address -- or before sensitive transactions, such as shipping a purchase to a new address. Without this countermeasure, an attacker may be able to execute sensitive transactions through a CSRF or XSS attack without needing to know the user's current credentials. Additionally, an attacker may get temporary physical access to a user's browser or steal their session ID to take over the user's session.

Reauthentication After Risk Events

Overview: Reauthentication is critical when an account has experienced high-risk activity such as account recovery, password resets, or suspicious behavior patterns. This section outlines when and how to trigger reauthentication to protect users and prevent unauthorized access. For further details, see the Require Re-authentication for Sensitive Features section.

When to Trigger Reauthentication

  • Suspicious Account Activity When unusual login patterns, IP address changes, or device enrollments occur
  • Account Recovery After users reset their passwords or change sensitive account details
  • Critical Actions For high-risk actions like changing payment details or adding new trusted devices

Reauthentication Mechanisms

  • Adaptive Authentication Use risk-based authentication models that adapt to the user's behavior and context
  • Multi-Factor Authentication (MFA) Require an additional layer of verification for sensitive actions or events
  • Challenge-Based Verification Prompt users to confirm their identity with a challenge question or secondary method

Implementation Recommendations

  • Minimize User Friction Ensure that reauthentication does not disrupt the user experience unnecessarily
  • Context-Aware Decisions Make reauthentication decisions based on context (e.g., geolocation, device type, prior patterns)
  • Secure Session Management Invalidate sessions after reauthentication and rotate tokens—see the OWASP Session Management Cheat Sheet