OWASP ASVS 5.0 (released May 2025) dedicates two of its most substantial chapters — V6 and V7 — to authentication and session management. Together, they set out requirements that cover the full lifecycle: from how passwords are created and stored to how sessions are generated, maintained, and destroyed. The standard is anchored in NIST SP 800-63B but written for a broader audience, and version 5.0 makes several significant changes from prior editions.
This article walks through both chapters at the requirement level, covering what the standard actually mandates at L1, L2, and L3 — useful both for developers building these systems and for assessors verifying them.
V6: Authentication
Password Requirements (V6.2)
ASVS 5.0 takes a clear position on passwords — one that aligns with NIST 800-63B's evidence-based stance rather than legacy security theater.
Length over complexity. Passwords must be at least 8 characters (6.2.1), but the standard is explicit that 15 characters is strongly recommended. At L2, passwords of at least 64 characters must be accepted (6.2.9). There is no maximum length restriction.
No composition rules. Requirement 6.2.5 prohibits rules that mandate specific character types — no minimum uppercase count, no required numbers, no forced special characters. Applications must accept passwords of any composition. This directly contradicts the "must include a number and a symbol" policies still common in enterprise software.
Breached password checking. At L1, passwords submitted during registration or change must be checked against a list of at least the top 3,000 common passwords matching the application's password policy (6.2.4). At L2, this extends to checking against a full breached-password dataset (6.2.12) — a live or periodically refreshed list of credentials known to be compromised from previous breaches. Services like the HIBP Passwords API satisfy this requirement.
Context-specific word blocking. L2 applications must maintain and apply a documented list of context-specific terms that cannot be used as passwords (6.2.11): organization names, product names, project codenames, department names, and similar. The list must be documented (6.1.2) before it can be enforced.
No forced rotation. Requirement 6.2.10 explicitly prohibits periodic password rotation. A password remains valid until it is either discovered to be compromised or the user voluntarily changes it. Forced rotation is not a mitigation — the standard treats it as a harmful policy that encourages weak incremental passwords.
Operational requirements. Passwords must be verified exactly as submitted — no truncation, no case normalization (6.2.8). Paste functionality, browser password helpers, and external password managers must be permitted (6.2.7). The type=password attribute is required, with an optional show/hide toggle for usability (6.2.6).
Multi-Factor Authentication (V6.3, V6.5, V6.6, V6.7)
The MFA requirements in ASVS 5.0 are tiered — and the bar gets meaningfully higher at each level.
L2: MFA or equivalent is mandatory. Requirement 6.3.3 states that L2 applications must use either a multi-factor authentication mechanism or a combination of independent single-factor mechanisms. Password alone is insufficient. The standard does not prescribe specific authenticator types at this level, giving teams flexibility to use TOTP authenticator apps, hardware tokens, or push notification-based second factors.
L3: Hardware-based, phishing-resistant authentication is required. At L3, one factor must be hardware-based and must provide compromise and impersonation resistance against phishing. The standard calls out specific mechanisms:
- Device-bound passkeys
- FIDO hardware keys requiring a physical user action (button press)
- eIDAS Level of Assurance High enforced authenticators
- NIST Authenticator Assurance Level 3 (AAL3) mechanisms
The intent is that hardware-bound keys cannot be phished — the private key never leaves the device, and the assertion is origin-bound. Relaxing this requirement at L3 must be accompanied by full documentation and a comprehensive set of compensating controls.
Email is not an acceptable factor. NIST SP 800-63 no longer considers email acceptable as an authentication mechanism, and ASVS 5.0 reflects this: requirement 6.3.6 prohibits email as either a single-factor or multi-factor authentication mechanism at L3. For L1 and L2, email-based flows are not explicitly banned but are discouraged — the standard's guidance on out-of-band mechanisms (V6.6) lists email alongside VOIP as "unsafe" and prohibited.
SMS and PSTN are restricted. Requirement 6.6.1 permits SMS/telephone OTPs at L1 and L2 only under specific conditions: the phone number must have been previously validated, stronger alternatives (such as TOTP) must also be offered, and users must be informed of the security risks. At L3, phone and SMS are completely disallowed.
TOTP and out-of-band codes. Across all MFA mechanisms, key requirements include:
- OTP codes must be single-use (6.5.1)
- Codes must be generated by a CSPRNG (6.5.3)
- Codes must have at least 20 bits of entropy — typically 4 random alphanumeric characters or 6 random digits (6.5.4)
- Out-of-band requests must expire within 10 minutes; TOTP codes have a 30-second maximum lifetime (6.5.5)
- OTP mechanisms must be protected against brute-force via rate limiting (6.6.3)
At L3, TOTP time validation must use a trusted server-side time source, not client-provided time (6.5.8), and biometric authentication is permitted only as a secondary factor alongside something-you-have or something-you-know (6.5.7).
FIDO/WebAuthn cryptographic authenticators. Section V6.7 covers hardware cryptographic devices specifically. Challenge nonces must be at least 64 bits and statistically unique over the device's lifetime (6.7.2). Certificates used to verify cryptographic authentication assertions must be stored in a way that protects them from modification (6.7.1).
Authentication Error Handling and Enumeration Prevention (V6.3)
Requirement 6.3.8 is an L3 control, but its implications reach any system handling sensitive data: valid users must not be deducible from failed authentication challenges. This covers:
- Error messages (valid account vs. invalid account must produce identical messages)
- HTTP response codes (no different 401 vs. 404 behavior based on account existence)
- Response timing (successful and failed lookups must take the same amount of time)
Crucially, the requirement extends to registration and password reset flows — not just login. A password reset that returns "we've sent instructions to your email" for known addresses but "no account found" for unknown ones is an enumeration vector.
At L1, the standard requires that anti-automation controls be implemented according to documented specifications (6.3.1) — rate limiting, CAPTCHA, and adaptive controls that defend against credential stuffing and brute force. These must be configured to prevent malicious account lockout as well as successful attacks.
Credential Storage (V11.4 cross-reference)
ASVS V6 governs password authentication, but the storage requirements live in V11 (Cryptography). Appendix C of ASVS 5.0 and the V11 chapter are unambiguous on approved algorithms. Password storage must use a purpose-built key derivation function — one of:
- Argon2id (preferred — winner of the Password Hashing Competition)
- bcrypt
- scrypt
- PBKDF2 with an approved underlying hash
MD5 and SHA-1 are prohibited for any cryptographic purpose (V11.4). Generic hash functions like SHA-256 and SHA-512 are also prohibited for password storage — even with a salt — because they are too fast and enable offline brute-force at scale.
For MFA secrets with less than 112 bits of entropy, ASVS requires storage using an approved password storage hashing algorithm with a 32-bit random salt (6.5.2). Lookup secrets at 112 bits of entropy or above may use a standard hash function.
Re-authentication for Sensitive Operations (V7.5)
The boundary between authentication and session management is relevant here. V7.5 covers re-authentication requirements directly:
- Sensitive account attribute changes — modifying email address, phone number, MFA configuration, or account recovery information requires full re-authentication before proceeding (7.5.1). An active session is not sufficient.
- Highly sensitive transactions — at L3, highly sensitive operations require step-up authentication with at least one additional factor or secondary verification (7.5.3).
- Password reset flows — the password reset path must not bypass enabled MFA mechanisms (6.4.3). This is a common implementation flaw where an application's password reset flow downgrades authentication assurance, letting an attacker with access to an email account bypass a TOTP second factor.
The distinction between "full re-authentication" (7.5.1) and "further authentication with at least one factor" (7.5.3) is intentional. Changing your MFA configuration requires proving you are the account owner from scratch. Approving a high-value transaction might only require re-entering a TOTP code.
Authentication Factor Lifecycle and Recovery (V6.4)
A few requirements worth highlighting:
- System-generated initial passwords and activation codes must be randomly generated, time-limited, and non-reusable — they must not become the long-term credential (6.4.1)
- Knowledge-based authentication ("secret questions") is prohibited (6.4.2)
- Recovery from a lost MFA factor requires identity proofing at the same assurance level as initial enrollment (6.4.4) — you cannot recover to a higher-assurance account via a weaker channel
- Administrators can initiate a password reset process for a user but must not be able to choose or know the resulting password (6.4.6) — this prevents privileged insiders from silently knowing user credentials
V7: Session Management
Token Generation and Session Fixation Prevention (V7.2)
The session token requirements in ASVS 5.0 are precise.
Entropy floor. Reference tokens (stateful session IDs) must be generated by a CSPRNG and possess at least 128 bits of entropy (7.2.3). UUIDs — which appear in V11 as explicitly not meeting entropy requirements for security-sensitive values — do not qualify on their own. The standard is specific: 128 bits from a CSPRNG, not 128 bits total from an identifier space where many values are predictable.
No static tokens. The application must use dynamically generated tokens, not static API secrets or keys (7.2.2). Using a static API key as a session credential is prohibited.
Session fixation prevention. A new session token must be generated upon every authentication and re-authentication, and the prior token must be terminated immediately (7.2.4). This directly addresses session fixation: an attacker who plants a known session token in a victim's browser before login cannot exploit that token after the victim authenticates, because the post-authentication token is always fresh.
Server-side validation only. All session token verification must occur at a trusted backend service (7.2.1). Client-side token validation is not acceptable.
Session Expiry (V7.3)
ASVS 5.0 deliberately avoids mandating specific timeout values. Both requirements in V7.3 are L2:
- Inactivity timeout (7.3.1): must be implemented, with the specific value determined by the application's risk analysis and documented security decisions
- Absolute maximum session lifetime (7.3.2): must be implemented, again with values based on documented decisions
The documentation requirement (7.1.1) is where the constraint lands: the chosen values must be documented, must be appropriate given other controls in place, and — critically — any deviation from NIST SP 800-63B re-authentication requirements must be explicitly justified.
NIST SP 800-63B's defaults (30-minute inactivity timeout, 12-hour absolute lifetime for AAL1; 30 minutes and 12 hours for AAL2; 15 minutes and 12 hours for AAL3) are the baseline. If an application's documented decisions deviate from these, the deviation must be justified.
Cookie Security Attributes
ASVS V7 explicitly delegates cookie-specific requirements to V3 (Web Frontend Security), but those requirements are directly relevant to any session management implementation using cookies.
V3.3 specifies:
Secureattribute — all cookies must carry theSecureattribute, ensuring they are transmitted only over HTTPSHttpOnlyattribute — session tokens and other values not intended for client-side JavaScript access must haveHttpOnlysetSameSiteattribute — must be set appropriately for the cookie's purpose; the standard notes this as a CSRF and UI redress defense- Cookie prefixes — cookie names must use either the
__Host-prefix (strongest binding — ties the cookie to the origin and prevents sub-domain scope) or the__Secure-prefix - Size limit — cookies must stay within 4096 bytes
The __Host- prefix is the stronger of the two options: it requires Secure, a root / path, and no Domain attribute, meaning the cookie cannot be sent to subdomains. For session cookies carrying high-value tokens, __Host- is the recommended choice where supported.
Session Termination and Invalidation (V7.4)
Session termination requirements are specific about what "logout" must actually do:
Immediate invalidation. When session termination is triggered — by logout, expiration, or any other mechanism — the application must immediately disallow further use of that session (7.4.1). For stateful sessions, backend session data must be deleted. For self-contained tokens (JWTs), this is more complex: the token will remain cryptographically valid until expiry, so the application must implement one of the following:
- A blocklist of terminated tokens
- A per-user revocation timestamp — tokens issued before the timestamp are rejected
- Per-user signing key rotation — rotating the key invalidates all tokens signed with the prior key
This is the operational link between V7 and V9 (Self-Contained Tokens). ASVS is explicit that "logout" for JWT-based sessions is not solved by deleting the token from the client — server-side revocation is required.
Account termination. All active sessions for a user account must be terminated when that account is disabled or deleted (7.4.2). Employee offboarding scenarios are specifically covered — there is no grace period.
Post-credential-change session handling. After any authentication factor change — password reset, MFA reconfiguration — the application must offer the user the option to terminate all other active sessions (7.4.3). This is an offer, not a force-termination, at L2; it gives the user the ability to revoke potentially compromised sessions while not disrupting legitimate concurrent access.
Visible logout. All authenticated pages must provide easy and visible access to logout functionality (7.4.4). Administrative access to session management is required: administrators must be able to terminate individual user sessions or all user sessions (7.4.5).
Concurrent Session Policy (V7.1)
The standard requires documentation of the maximum number of concurrent sessions allowed per account, and what happens when that limit is reached (7.1.2). The ASVS does not specify a number — "one active session per account" is not mandated — but the policy must be deliberate and documented. Common patterns include:
- Allowing unlimited concurrent sessions (document the rationale)
- Capping at N sessions and either rejecting new logins or invalidating the oldest session when the limit is exceeded
- Using device fingerprinting or named sessions to give users visibility and control
Federated Session Considerations (V7.6)
For applications participating in federated identity scenarios — acting as a Relying Party against an IdP, or operating within an SSO ecosystem — additional requirements apply:
- Session lifetime and termination between Relying Parties and Identity Providers must behave as documented (7.6.1). When the maximum time between IdP authentication events is reached, re-authentication must be enforced.
- New application sessions must require either explicit user consent or a deliberate user action (7.6.2). Passive creation of new sessions — where the user is silently logged in without interaction — is prohibited.
The IdP-specific authentication requirements in V6.8 are also relevant here. If an application relies on a separate Identity Provider and requires specific authentication strength (e.g., MFA having been performed), it must verify this using the IdP's returned data — claims like OIDC's acr, amr, and auth_time (6.8.4). If the IdP doesn't provide this information, the application must have a documented fallback that assumes the minimum authentication strength was used.
Cross-References to V9 and V10
ASVS 5.0 is structured to avoid duplicating requirements across chapters. Two chapters are directly relevant alongside V6 and V7:
V9 (Self-Contained Tokens) covers JWT and SAML assertion security: signature validation, algorithm allowlisting, preventing the alg: "none" attack, exp/nbf/aud claim enforcement, and key injection attacks through header parameters like jku and x5u. Any application using JWTs as session tokens — rather than opaque reference tokens — must satisfy V9 in addition to V7. The revocation complexity noted in V7.4.1 flows directly from the stateless nature of self-contained tokens covered in V9.
V10 (OAuth and OIDC) governs applications acting as OAuth clients, authorization servers, resource servers, or OIDC relying parties. Key overlaps with V6/V7 include: PKCE requirements for the authorization code flow, authorization code single-use enforcement, prohibition of the implicit grant and Resource Owner Password Credentials grant, and the OIDC session management requirements for front-channel and back-channel logout. For applications integrating external identity providers, V10 is where the implementation details live; V6.8 sets the application-level verification requirements.
What Changes at Each Level
To summarize the level structure across V6 and V7:
L1 establishes the non-negotiable floor: minimum password length, common password checks, brute-force defenses, default account removal, session CSPRNG generation with 128-bit entropy, backend session validation, new session token on login, and immediate logout invalidation.
L2 adds mandatory MFA, breached password checking, context-specific word blocking, forced-rotation prohibition, 64-character password support, inactivity and absolute session timeouts (with documented values), re-authentication before sensitive account changes, and user session visibility and termination controls.
L3 requires hardware-backed phishing-resistant authentication, prohibits email and SMS as factors, mandates notification of suspicious authentication events, and requires step-up authentication for high-value operations. The step from L2 to L3 is significant: FIDO2/WebAuthn infrastructure, device enrollment workflows, and recovery paths that maintain the same assurance level are all required. Password-plus-TOTP is not the end state for high-assurance applications.
Sources
- OWASP ASVS 5.0.0 (May 2025): owasp.org/www-project-application-security-verification-standard
- NIST SP 800-63B: pages.nist.gov/800-63-3/sp800-63b.html
- OWASP Password Storage Cheat Sheet: cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
- OWASP Session Management Cheat Sheet: cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html