OWASP ASVS 3.0 & 4.0 Comparison
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

View only
OWASP ASVS Comparison of Section 2: Authentication Verification Requirements
By Bruce K. Marshall - PasswordResearch.com - @PwdRschGrey cells indicate the lack of a directly corresponding requirement
ASVS v4.0ASVS v3.0.1
2.1.1 Verify that user set passwords are at least 12 characters in length.
2.1.2 Verify that passwords 64 characters or longer are permitted.2.7 Verify password entry fields allow, or encourage, the use of passphrases, and do not prevent password managers, long passphrases or highly complex passwords being entered.
2.1.3 Verify that passwords can contain spaces and truncation is not performed. Consecutive multiple spaces MAY optionally be coalesced.
2.1.4 Verify that Unicode characters are permitted in passwords. A single Unicode code point is considered a character, so 12 emoji or 64 kanji characters should be valid and permitted.
2.1.5 Verify users can change their password.
2.1.6 Verify that password change functionality requires the user's current and new password.2.9 Verify that the changing password functionality includes the old password, the new password, and a password confirmation.
2.1.7 Verify that passwords submitted during account registration, login, and password change are checked against a set of breached passwords either locally (such as the top 1,000 or 10,000 most common passwords which match the system's password policy) or using an external API. If using an API a zero knowledge proof or other mechanism should be used to ensure that the plain text password is not sent or used in verifying the breach status of the password. If the password is breached, the application must require the user to set a new non-breached password.2.27 Verify that measures are in place to block the use of commonly chosen passwords and weak passphrases.
2.1.8 Verify that a password strength meter is provided to help users set a stronger password.
2.1.9 Verify that there are 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.
2.1.10 Verify that there are no periodic credential rotation or password history requirements.2.25 Verify that the system can be configured to disallow the use of a configurable number of previous passwords.
2.1.11 Verify that "paste" functionality, browser password helpers, and external password managers are permitted.2.33 Browser autocomplete, and integration with password managers are permitted unless prohibited by risk based policy.
2.1.12 Verify that the user can choose to either temporarily view the entire masked password, or temporarily view the last typed character of the password on platforms that do not have this as native functionality.
2.2.1 Verify that anti-automation controls are effective at mitigating breached credential testing, brute force, and account lockout attacks. Such controls include blocking the most common breached passwords, soft lockouts, rate limiting, CAPTCHA, ever increasing delays between attempts, IP address restrictions, or risk-based restrictions such as location, first login on a device, recent attempts to unlock the account, or similar. Verify that no more than 100 failed attempts per hour is possible on a single account.2.20 Verify that anti-automation is in place to prevent breached credential testing, brute forcing, and account lockout attacks.
2.2.2 Verify that the use of weak authenticators (such as SMS and email) is limited to secondary verification and transaction approval and not as a replacement for more secure authentication methods. Verify that stronger methods are offered before weak methods, users are aware of the risks, or that proper measures are in place to limit the risks of account compromise.
2.2.3 Verify that secure notifications are sent to users after updates to authentication details, such as credential resets, email or address changes, logging in from unknown or risky locations. The use of push notifications - rather than SMS or email - is preferred, but in the absence of push notifications, SMS or email is acceptable as long as no sensitive information is disclosed in the notification.
2.2.4 Verify impersonation resistance against phishing, such as the use of multi-factor authentication, cryptographic devices with intent (such as connected keys with a push to authenticate), or at higher AAL levels, client-side certificates.2.26 Verify that risk based re-authentication, two factor or transaction signing is in place for high value transactions.
2.31 Verify that if an application allows users to authenticate, they can authenticate using two-factor authentication or other strong authentication, or any similar scheme that provides protection against username + password disclosure.
2.2.5 Verify that where a credential service provider (CSP) and the application verifying authentication are separated, mutually authenticated TLS is in place between the two endpoints.Somewhat related to 2.16 Verify that credentials are transported using a suitable encrypted link and that all pages/functions that require a user to enter credentials are done so using an encrypted link.
2.2.6 Verify replay resistance through the mandated use of OTP devices, cryptographic authenticators, or lookup codes.
2.2.7 Verify intent to authenticate by requiring the entry of an OTP token or user-initiated action such as a button press on a FIDO hardware key.
2.3.1 Verify system generated initial passwords or activation codes SHOULD be securely randomly generated, SHOULD be at least 6 characters long, and MAY contain letters and numbers, and expire after a short period of time. These initial secrets must not be permitted to become the long term password.
2.3.2 Verify that enrollment and use of subscriber-provided authentication devices are supported, such as a U2F or FIDO tokens.
2.3.3 Verify that renewal instructions are sent with sufficient time to renew time bound authenticators.
2.4.1 Verify that passwords are stored in a form that is resistant to offline attacks. Passwords SHALL be salted and hashed using an approved oneway key derivation or password hashing function. Key derivation and password hashing functions take a password, a salt, and a cost factor as inputs when generating a password hash.2.13 Verify that account passwords are one way hashed with a salt, and there is sufficient work factor to defeat brute force and password hash recovery attacks.
2.4.2 Verify that the salt is at least 32 bits in length and be chosen arbitrarily to minimize salt value collisions among stored hashes. For each credential, a unique salt value and the resulting hash SHALL be stored.
2.4.3 Verify that if PBKDF2 is used, the iteration count SHOULD be as large as verification server performance will allow, typically at least 100,000 iterations.
2.4.4 Verify that if bcrypt is used, the work factor SHOULD be as large as verification server performance will allow, typically at least 13.
2.4.5 Verify that an additional iteration of a key derivation function is performed, using a salt value that is secret and known only to the verifier. Generate the salt value using an approved random bit generator [SP 800-90Ar1] and provide at least the minimum security strength specified in the latest revision of SP 800-131A. The secret salt value SHALL be stored separately from the hashed passwords (e.g., in a specialized device like a hardware security module).
2.5.1 Verify that a system generated initial activation or recovery secret is not sent in clear text to the user.2.16 Verify that credentials are transported using a suitable encrypted link and that all pages/functions that require a user to enter credentials are done so using an encrypted link.
2.5.2 Verify password hints or knowledge-based authentication (so-called "secret questions") are not present.2.24 Verify that if shared knowledge based questions (also known as "secret questions") are required, the questions do not violate privacy laws and are sufficiently strong to protect accounts from malicious recovery.
2.5.3 Verify password credential recovery does not reveal the current password in any way.2.17 Verify that the forgotten password function and other recovery paths do not reveal the current password and that the new password is not sent in clear text to the user.
2.5.4 Verify shared or default accounts are not present (e.g. "root", "admin", or "sa").2.19 Verify there are no default passwords in use for the application framework or any components used by the application (such as “admin/password”).
2.5.5 Verify that if an authentication factor is changed or replaced, that the user is notified of this event.
2.5.6 Verify forgotten password, and other recovery paths use a secure recovery mechanism, such as TOTP or other soft token, mobile push, or another offline recovery mechanism.2.22 Verify that forgotten password and other recovery paths use a TOTP or other soft token, mobile push, or other offline recovery mechanism. Use of a random value in an e-mail or SMS should be a last resort and is known weak.
2.5.7 Verify that if OTP or multi-factor authentication factors are lost, that evidence of identity proofing is performed at the same level as during enrollment.
2.6.1 Verify that lookup secrets can be used only once.
2.6.2 Verify that lookup secrets have sufficient randomness (112 bits of entropy), or if less than 112 bits of entropy, salted with a unique and random 32-bit salt and hashed with an approved one-way hash.
2.6.3 Verify that lookup secrets are resistant to offline attacks, such as predictable values.
2.7.1 Verify that clear text out of band (NIST "restricted") authenticators, such as SMS or PSTN, are not offered by default, and stronger alternatives such as push notifications are offered first.
2.7.2 Verify that the out of band verifier expires out of band authentication requests, codes, or tokens after 10 minutes.
2.7.3 Verify that the out of band verifier authentication requests, codes, or tokens are only usable once, and only for the original authentication request.
2.7.4 Verify that the out of band authenticator and verifier communicates over a secure independent channel.
2.7.5 Verify that the out of band verifier retains only a hashed version of the authentication code.
2.7.6 Verify that the initial authentication code is generated by a secure random number generator, containing at least 20 bits of entropy (typically a six digital random number is sufficient).
2.8.1 Verify that time-based OTPs have a defined lifetime before expiring.
2.8.2 Verify that symmetric keys used to verify submitted OTPs are highly protected, such as by using a hardware security module or secure operating system based key storage.
2.8.3 Verify that approved cryptographic algorithms are used in the generation, seeding, and verification.
2.8.4 Verify that time-based OTP can be used only once within the validity period.
2.8.5 Verify that if a time-based multi factor OTP token is re-used during the validity period, it is logged and rejected with secure notifications being sent to the holder of the device.
2.8.6 Verify physical single factor OTP generator can be revoked in case of theft or other loss. Ensure that revocation is immediately effective across logged in sessions, regardless of location.
2.8.7 Verify that biometric authenticators are limited to use only as secondary factors in conjunction with either something you have and something you know.
2.9.1 Verify that cryptographic keys used in verification are stored securely and protected against disclosure, such as using a TPM or HSM, or an OS service that can use this secure storage.
2.9.2 Verify that the challenge nonce is at least 64 bits in length, and statistically unique or unique over the lifetime of the cryptographic device.
2.9.3 Verify that approved cryptographic algorithms are used in the generation, seeding, and verification.
2.10.1 Verify that integration secrets do not rely on unchanging passwords, such as API keys or shared privileged accounts.
2.10.2 Verify that if passwords are required, the credentials are not a default account.
2.10.3 Verify that passwords are stored with sufficient protection to prevent offline recovery attacks, including local system access.2.21 Verify that all authentication credentials for accessing services external to the application are encrypted and stored in a protected location.
2.10.4 Verify passwords, integrations with databases and third-party systems, seeds and internal secrets, and API keys are managed securely and not included in the source code or stored within source code repositories. Such storage SHOULD resist offline attacks. The use of a secure software key store (L1), hardware trusted platform module (TPM), or a hardware security module (L3) is recommended for password storage.2.29 Verify that secrets, API keys, and passwords are not included in the source code, or online source code repositories.
Relevant practices from other sections
2.1 Verify all pages and resources by default require authentication except those specifically intended to be public (Principle of complete mediation).
2.2 Verify that forms containing credentials are not filled in by the application. Pre-filling by the application implies that credentials are stored in plaintext or a reversible format, which is explicitly prohibited.
2.4 Verify all authentication controls are enforced on the server side.
2.6 Verify all authentication controls fail securely to ensure attackers cannot log in.
[Somewhat covered by 2.5.6, but other elements do not map to this requirement.]2.8 Verify all account identity authentication functions (such as update profile, forgot password, disabled / lost token, help desk or IVR) that might regain access to the account are at least as resistant to attack as the primary authentication mechanism.
7.1.1 Verify that the application does not log credentials or payment details. Session tokens should only be stored in logs in an irreversible, hashed form.
7.1.3 Verify that the application logs security relevant events including successful and failed authentication events, access control failures, deserialization failures and input validation failures.
2.11 Verify that all authentication decisions can be logged, without storing sensitive session identifiers or passwords. This should include requests with relevant metadata needed for security investigations.
2.18 Verify that information enumeration is not possible via login, password reset, or forgot account functionality.
2.23 Verify that account lockout is divided into soft and hard lock status, and these are not mutually exclusive. If an account is temporarily soft locked out due to a brute force attack, this should not reset the hard lock status.
4.3.3 Verify the application has additional authorization (such as step up or adaptive authentication) for lower value systems, and / or segregation of duties for high value applications to enforce anti-fraud controls as per the risk of application and past fraud.2.26 Verify that risk based re-authentication, two factor or transaction signing is in place for high value transactions.
2.28 Verify that all authentication challenges, whether successful or failed, should respond in the same average response time.
2.32 Verify that administrative interfaces are not accessible to untrusted parties.