V6.5.8 TOTP time source validation
Requirement 6.5.8 applies to Level 3. Time-based one-time passwords (TOTPs) must be checked based on a time source from a trusted service and not from an untrusted or client provided time.
asvs/v6-authentication
49 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
V6.1.1 Authentication documentation for attack prevention controls
Requirement 6.1.1 applies to Level 1. The application documentation must define how controls such as rate limiting, anti-automation, and adaptive response are used to defend against attacks such as credential stuffing and password brute force. The documentation must make clear how these controls are configured and prevent malicious account lockout.
V6.1.2 Context-specific password word list documentation
Requirement 6.1.2 applies to Level 2. A list of context-specific words must be documented in order to prevent their use in passwords. The list could include permutations of organization names, product names, system identifiers, project codenames, department or role names, and similar.
V6.1.3 Multiple authentication pathways documentation
Requirement 6.1.3 applies to Level 2. If the application includes multiple authentication pathways, these must all be documented together with the security controls and authentication strength which must be consistently enforced across them.
V6.2.1 Minimum password length requirement
Requirement 6.2.1 applies to Level 1. User set passwords must be at least 8 characters in length, although a minimum of 15 characters is strongly recommended.
V6.2.2 Password change functionality
Requirement 6.2.2 applies to Level 1. Users must be able to change their password.
V6.2.3 Password change requires current and new password
Requirement 6.2.3 applies to Level 1. Password change functionality must require the user's current and new password.
V6.2.4 Password checked against top 3000 common passwords
Requirement 6.2.4 applies to Level 1. Passwords submitted during account registration or password change must be checked against an available set of at least the top 3000 passwords which match the application's password policy, for example by minimum length.
V6.2.5 No character composition requirements for passwords
Requirement 6.2.5 applies to Level 1. Passwords of any composition must be accepted, without rules limiting the type of characters permitted. There must be no requirement for a minimum number of upper or lower case characters, numbers, or special characters.
V6.2.6 Password input masking
Requirement 6.2.6 applies to Level 1. Password input fields must use type=password to mask the entry. Applications may allow the user to temporarily view the entire masked password, or the last typed character of the password.
V6.2.7 Paste functionality and password managers permitted
Requirement 6.2.7 applies to Level 1. Paste functionality, browser password helpers, and external password managers must be permitted.
V6.2.8 Password verification without modification
Requirement 6.2.8 applies to Level 1. The application must verify the user's password exactly as received from the user, without any modifications such as truncation or case transformation.
V6.2.9 Support for 64-character passwords
Requirement 6.2.9 applies to Level 2. Passwords of at least 64 characters must be permitted.
V6.2.10 Password validity until compromised or rotated
Requirement 6.2.10 applies to Level 2. A user's password must stay valid until it is discovered to be compromised or the user rotates it. The application must not require periodic credential rotation.
V6.2.11 Context-specific words prevent easy guessing
Requirement 6.2.11 applies to Level 2. The documented list of context-specific words must be used to prevent easy to guess passwords being created.
V6.2.12 Breached password checking
Requirement 6.2.12 applies to Level 2. Passwords submitted during account registration or password changes must be checked against a set of breached passwords.
V6.3.1 Controls against credential stuffing and brute force
Requirement 6.3.1 applies to Level 1. Controls to prevent attacks such as credential stuffing and password brute force must be implemented according to the application's security documentation.
V6.3.2 Default user accounts disabled or removed
Requirement 6.3.2 applies to Level 1. Default user accounts such as 'root', 'admin', or 'sa' must not be present in the application or must be disabled.
V6.5.6 Revocation of authentication factors
Requirement 6.5.6 applies to Level 3. Any authentication factor, including physical devices, must be revocable in case of theft or other loss.
V6.5.7 Biometric authentication as secondary factor only
Requirement 6.5.7 applies to Level 3. Biometric authentication mechanisms must only be used as secondary factors together with either something you have or something you know.
V6.3.3 Multi-factor authentication or equivalent required
Requirement 6.3.3 applies to Level 2, with enhanced requirements for Level 3. For Level 2, either a multi-factor authentication mechanism or a combination of single-factor authentication mechanisms must be used to access the application. For Level 3, one of the factors must be a hardware-based authentication mechanism which provides compromise and impersonation resistance against phishing attacks while verifying the intent to authenticate by requiring a user-initiated action such as a button press on a FIDO hardware key or a mobile phone. Relaxing any of the considerations in this requirement requires a fully documented rationale and a comprehensive set of mitigating controls.
V6.3.4 Consistent enforcement across multiple authentication pathways
Requirement 6.3.4 applies to Level 2. If the application includes multiple authentication pathways, there must be no undocumented pathways and security controls and authentication strength must be enforced consistently.
V6.3.5 Notification of suspicious authentication attempts
Requirement 6.3.5 applies to Level 3. Users must be notified of suspicious authentication attempts, whether successful or unsuccessful. This may include authentication attempts from an unusual location or client, partially successful authentication with only one of multiple factors, authentication attempts after a long period of inactivity, or successful authentication after several unsuccessful attempts.
V6.3.6 Email prohibited as authentication mechanism
Requirement 6.3.6 applies to Level 3. Email must not be used as either a single-factor or multi-factor authentication mechanism.
V6.3.7 Notification of authentication detail updates
Requirement 6.3.7 applies to Level 3. Users must be notified after updates to authentication details, such as credential resets or modification of the username or email address.
V6.3.8 User enumeration prevention in authentication challenges
Requirement 6.3.8 applies to Level 3. Valid users cannot be deduced from failed authentication challenges, such as by basing on error messages, HTTP response codes, or different response times. Registration and forgot password functionality must also have this protection.
V6.4.1 Secure initial passwords and activation codes
Requirement 6.4.1 applies to Level 1. System generated initial passwords or activation codes must be securely randomly generated, follow the existing password policy, and expire after a short period of time or after they are initially used. These initial secrets must not be permitted to become the long term password.
V6.4.2 No password hints or knowledge-based authentication
Requirement 6.4.2 applies to Level 1. Password hints or knowledge-based authentication, so-called 'secret questions', must not be present.
V6.4.3 Secure password reset without bypassing MFA
Requirement 6.4.3 applies to Level 2. A secure process for resetting a forgotten password must be implemented, that does not bypass any enabled multi-factor authentication mechanisms.
V6.4.4 Identity proofing for lost MFA factors
Requirement 6.4.4 applies to Level 2. If a multi-factor authentication factor is lost, evidence of identity proofing must be performed at the same level as during enrollment.
V6.4.5 Renewal instructions for expiring authentication mechanisms
Requirement 6.4.5 applies to Level 3. Renewal instructions for authentication mechanisms which expire must be sent with enough time to be carried out before the old authentication mechanism expires, configuring automated reminders if necessary.
V6.4.6 Administrative password reset restrictions
Requirement 6.4.6 applies to Level 3. Administrative users can initiate the password reset process for the user, but this must not allow them to change or choose the user's password. This prevents a situation where they know the user's password.
V6.5.1 Single use of lookup secrets, OTPs, and out-of-band codes
Requirement 6.5.1 applies to Level 2. Lookup secrets, out-of-band authentication requests or codes, and time-based one-time passwords (TOTPs) must only be successfully usable once.
V6.5.2 Lookup secret storage with entropy requirements
Requirement 6.5.2 applies to Level 2. When stored in the application's backend, lookup secrets with less than 112 bits of entropy (19 random alphanumeric characters or 34 random digits) must be hashed with an approved password storage hashing algorithm that incorporates a 32-bit random salt. A standard hash function can be used if the secret has 112 bits of entropy or more.
V6.5.3 CSPRNG for generating authentication secrets
Requirement 6.5.3 applies to Level 2. Lookup secrets, out-of-band authentication codes, and time-based one-time password seeds must be generated using a Cryptographically Secure Pseudorandom Number Generator (CSPRNG) to avoid predictable values.
V6.5.4 Minimum entropy for lookup secrets and out-of-band codes
Requirement 6.5.4 applies to Level 2. Lookup secrets and out-of-band authentication codes must have a minimum of 20 bits of entropy. Typically 4 random alphanumeric characters or 6 random digits is sufficient.
V6.5.5 Lifetime limits for out-of-band and TOTP authentication
Requirement 6.5.5 applies to Level 2. Out-of-band authentication requests, codes, or tokens, as well as time-based one-time passwords (TOTPs) must have a defined lifetime. Out of band requests must have a maximum lifetime of 10 minutes and for TOTP a maximum lifetime of 30 seconds.
V6.6.1 PSTN and SMS authentication restrictions
Requirement 6.6.1 applies to Level 2, with stricter requirements for Level 3. For Level 2, authentication mechanisms using the Public Switched Telephone Network (PSTN) to deliver One-time Passwords (OTPs) via phone or SMS must be offered only when the phone number has previously been validated, alternate stronger methods such as Time based One-time Passwords are also offered, and the service provides information on their security risks to users. For Level 3 applications, phone and SMS must not be available as options.
V6.6.2 Out-of-band code binding to original request
Requirement 6.6.2 applies to Level 2. Out-of-band authentication requests, codes, or tokens must be bound to the original authentication request for which they were generated and must not be usable for a previous or subsequent one.
V6.6.3 Brute force protection for code-based out-of-band authentication
Requirement 6.6.3 applies to Level 2. A code based out-of-band authentication mechanism must be protected against brute force attacks by using rate limiting. Consider also using a code with at least 64 bits of entropy.
V6.6.4 Push notification rate limiting to prevent push bombing
Requirement 6.6.4 applies to Level 3. Where push notifications are used for multi-factor authentication, rate limiting must be used to prevent push bombing attacks. Number matching may also mitigate this risk.
V6.7.1 Protection of cryptographic authentication certificates
Requirement 6.7.1 applies to Level 3. The certificates used to verify cryptographic authentication assertions must be stored in a way that protects them from modification.
V6.7.2 Challenge nonce requirements for cryptographic authentication
Requirement 6.7.2 applies to Level 3. The challenge nonce must be at least 64 bits in length, and statistically unique or unique over the lifetime of the cryptographic device.
V6.8.1 Identity spoofing prevention across multiple IdPs
Requirement 6.8.1 applies to Level 2. If the application supports multiple identity providers (IdPs), the user's identity must not be spoofed via another supported identity provider by using the same user identifier. The standard mitigation is for the application to register and identify the user using a combination of the IdP ID serving as a namespace and the user's ID in the IdP.
V6.8.2 Validation of digital signatures on authentication assertions
Requirement 6.8.2 applies to Level 2. The presence and integrity of digital signatures on authentication assertions such as on JWTs or SAML assertions must always be validated, rejecting any assertions that are unsigned or have invalid signatures.
V6.8.3 SAML assertion replay attack prevention
Requirement 6.8.3 applies to Level 2. SAML assertions must be uniquely processed and used only once within the validity period to prevent replay attacks.
V6.8.4 IdP authentication strength verification
Requirement 6.8.4 applies to Level 2. If an application uses a separate Identity Provider (IdP) and expects specific authentication strength, methods, or recentness for specific functions, the application must verify this using the information returned by the IdP. For example, if OIDC is used, this might be achieved by validating ID Token claims such as 'acr', 'amr', and 'auth_time' if present. If the IdP does not provide this information, the application must have a documented fallback approach that assumes that the minimum strength authentication mechanism was used, for example single-factor authentication using username and password.
V6 Level 2 multi-factor authentication mandate
For Level 2 applications, multi-factor authentication (MFA) must be forced. Level 3 applications must use hardware-based authentication, performed in an attested and trusted execution environment (TEE). This could include device-bound passkeys, eIDAS Level of Assurance (LoA) High enforced authenticators, authenticators with NIST Authenticator Assurance Level 3 (AAL3) assurance, or an equivalent mechanism.
Authentication is establishing authenticity with impersonation resistance
Authentication is the process of establishing or confirming the authenticity of an individual or device. It involves verifying claims made by a person or about a device, ensuring resistance to impersonation, and preventing the recovery or interception of passwords.