OWASP Application Security Verification Standard 5.0.0
This section contains requirements detailing the authentication documentation that should be main‑ tained for an application. This is crucial for implementing and assessing how the relevant authenti‑ cation controls should be configured.
| # | Level | Requirement | Status | How We Comply | What to Do |
|---|---|---|---|---|---|
| 6.1.1 | 1 | Verify that application documentation defines 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. | Partial | Rate limiting configured via setLoginAttemptProtection(). Documentation of controls not yet formalized in ASVS format. | Per-project: document setLoginAttemptProtection($maxAttempts, $timeout) values and rationale in project security docs. |
| 6.1.2 | 2 | Verify that a list of context‑specific words is 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. | Partial | Context-specific word list not yet documented or implemented. | Per-project: create context-specific word list (org name, product name, domain) for password deny list. |
| 6.1.3 | 2 | Verify that, if the application includes multiple authentication pathways, these are all documented together with the security controls and authentication strength which must be consistently enforced across them. | Compliant | Single authentication pathway (email/username + password). No multiple pathways. | — |
Passwords, called "Memorized Secrets"by NIST SP 800‑63, include passwords, passphrases, PINs, unlock patterns, and picking the correct kitten or another image element. They are generally con‑ sidered "something you know"and are often used as a single‑factor authentication mechanism. As such, this section contains requirements for making sure that passwords are created and handled securely. Most of the requirements are L1 as they are most important at that level. From L2 on‑ wards, multi‑factor authentication mechanisms are required, where passwords may be one of those factors. The requirements in this section mostly relate to § 5.1.1.2 of NIST's Guidance.
| # | Level | Requirement | Status | How We Comply | What to Do |
|---|---|---|---|---|---|
| 6.2.1 | 1 | Verify that user set passwords are at least 8 characters in length although a minimum of 15 characters is strongly recommended. | Compliant | Configurable password policy stored in Configuration table. Minimum length enforced (default 8, configurable). NewPasswordFormTrait validates against policy. | — |
| 6.2.2 | 1 | Verify that users can change their password. | Compliant | Password change available via NewPassword form (Account page / admin-initiated reset). | — |
| 6.2.3 | 1 | Verify that password change functionality requires the user's current and new password. | Compliant | ChangePasswordFormTrait on Account page requires current password + new password. Password recovery via email token (NewPasswordFormTrait) does not require current password by design — recovery flow for users who lost access. | — |
| 6.2.4 | 1 | Verify that passwords submitted during account registration or password change are checked against an available set of, at least, the top 3000 passwords which match the application's password policy, e.g. minimum length. | Compliant | BreachedPasswordChecker checks against local top 10k common passwords list (resources/common-passwords.txt). Integrated into NewPasswordFormTrait::validateForm(). | — |
| 6.2.5 | 1 | Verify that passwords of any composition can be used, 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. | Compliant | Password policy is disabled by default (enabled: false in Configuration). No composition rules enforced — passwords of any composition accepted. Only minimum length (8 chars) required at form level. | — |
| 6.2.6 | 1 | Verify that password input fields 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. | Compliant | Password input fields use type=password. Nette forms default behavior. | — |
| 6.2.7 | 1 | Verify that "paste"functionality, browser password helpers, and external password managers are permitted. | Compliant | No restrictions on paste functionality or password managers. Standard HTML inputs. | — |
| 6.2.8 | 1 | Verify that the application verifies the user's password exactly as received from the user, without any modifications such as truncation or case transformation. | Compliant | Passwords verified as-is using password_verify(). No truncation or case transformation. | — |
| 6.2.9 | 2 | Verify that passwords of at least 64 characters are permitted. | Compliant | No maximum password length limit enforced by the application. | — |
| 6.2.10 | 2 | Verify that a user's password stays valid until it is discovered to be compromised or the user rotates it. The application must not require periodic credential rotation. | Compliant | No periodic credential rotation required. Passwords valid until user changes them. | — |
| 6.2.11 | 2 | Verify that the documented list of context specific words is used to prevent easy to guess passwords being created. | Partial | Context-specific word list not yet implemented. | Pending fancyadmin: add setContextWordList(array) to BreachedPasswordChecker. Per-project: configure via DI setup: in common.neon. |
| 6.2.12 | 2 | Verify that passwords submitted during account registration or password changes are checked against a set of breached passwords. | Compliant | BreachedPasswordChecker checks against local top 10k common passwords list and HaveIBeenPwned Pwned Passwords API (k-Anonymity, 500ms timeout, fail-open). Checked during password change in NewPasswordFormTrait::validateForm(). | — |
This section contains general requirements for the security of authentication mechanisms as well as setting out the different expectations for levels. L2 applications must force the use of multi‑factor authentication (MFA). L3 applications must use hardware‑based authentication, performed in an at‑ tested and trusted execution environment (TEE). This could include device‑bound passkeys, eIDAS Level of Assurance (LoA) High enforced authenticators, authenticators with NIST Authenticator As‑ surance Level 3 (AAL3) assurance, or an equivalent mechanism. While this is a relatively aggressive stance on MFA, it is critical to raise the bar around this to protect users, and any attempt to relax these requirements should be accompanied by a clear plan on how the risks around authentication will be mitigated, taking into account NIST's guidance and research on the topic. Note that at the time of release, NIST SP 800‑63 considers email as not acceptable as an authentication mechanism (archived copy). The requirements in this section relate to a variety of sections of NIST's Guidance, including: § 4.2.1, § 4.3.1, § 5.2.2, and § 6.1.2.
| # | Level | Requirement | Status | How We Comply | What to Do |
|---|---|---|---|---|---|
| 6.3.1 | 1 | Verify that controls to prevent attacks such as credential stuffing and password brute force are implemented according to the application's security documentation. | Compliant | IP-based rate limiting via DoctrineAuthenticator. Configurable maxLoginAttempts and loginAttemptTimeout. | — |
| 6.3.2 | 1 | Verify that default user accounts (e.g., "root", "admin", or "sa") are not present in the application or are disabled. | Compliant | No default user accounts. All accounts created through application flows. | — |
| 6.3.3 | 2 | Verify that either a multi‑factor authentication mechanism or a combination of single‑factor authentication mechanisms, must be used in order to access the application. For L3, 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. | Partial | MFA not yet implemented. Single-factor authentication (password) only. MFA is required for L2 compliance. | Pending fancyadmin: implement TOTP MFA. IdentityTrait already uses DoctrineAuthenticator\OTP\IdentityTrait as foundation. |
| 6.3.4 | 2 | Verify that, if the application includes multiple authentication pathways, there are no undocumented pathways and that security controls and authentication strength are enforced consistently. | Compliant | Single authentication pathway (email + password). No undocumented pathways. | — |
| 6.3.5 | 3 | Verify that users are notified of suspicious authentication attempts (successful or unsuccessful). This may include authentication attempts from an unusual location or client, partially successful authentication (only one of multiple factors), an authentication attempt after a long period of inactivity or a successful authentication after several unsuccessful attempts. | |||
| 6.3.6 | 3 | Verify that email is not used as either a single‑factor or multi‑factor authentication mechanism. | |||
| 6.3.7 | 3 | Verify that users are notified after updates to authentication details, such as credential resets or modification of the username or email address. | |||
| 6.3.8 | 3 | Verify that 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. | Compliant | Generic error message 'wrongEmailOrPassword' for all auth failures. No user enumeration via error messages. | — |
Authentication factors may include passwords, soft tokens, hardware tokens, and biometric devices. Securely handling the lifecycle of these mechanisms is critical to the security of an application, and this section includes requirements related to this. The requirements in this section mostly relate to § 5.1.1.2 or § 6.1.2.3 of NIST's Guidance.
| # | Level | Requirement | Status | How We Comply | What to Do |
|---|---|---|---|---|---|
| 6.4.1 | 1 | Verify that system generated initial passwords or activation codes are 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. | Compliant | Initial passwords set via secure email link with token (OnetimeTokenService). Token expires. User must set their own password. | — |
| 6.4.2 | 1 | Verify that password hints or knowledge‑based authentication (so‑called "secret questions") are not present. | Compliant | No password hints or secret questions in the application. | — |
| 6.4.3 | 2 | Verify that a secure process for resetting a forgotten password is implemented, that does not bypass any enabled multi‑factor authentication mechanisms. | Compliant | Password reset via secure email link using OnetimeTokenService. Token-based recovery flow. | — |
| 6.4.4 | 2 | Verify that if a multi‑factor authentication factor is lost, evidence of identity proofing is performed at the same level as during enrollment. | Out of scope | MFA not yet implemented. | — |
| 6.4.5 | 3 | Verify that renewal instructions for authentication mechanisms which expire are sent with enough time to be carried out before the old authentication mechanism expires, configuring automated reminders if necessary. | |||
| 6.4.6 | 3 | Verify that administrative users can initiate the password reset process for the user, but that this does not allow them to change or choose the user's password. This prevents a situation where they know the user's password. | Compliant | Admin initiates password reset which sends email to user. Admin cannot set or see the password. | — |
This section provides general guidance that will be relevant to various different multi‑factor authen‑ tication methods. The mechanisms include: • Lookup Secrets • Time based One‑time Passwords (TOTPs) • Out‑of‑Band mechanisms Lookup secrets are pre‑generated lists of secret codes, similar to Transaction Authorization Num‑ bers (TAN), social media recovery codes, or a grid containing a set of random values. This type of authentication mechanism is considered "something you have"because the codes are deliberately not memorable so will need to be stored somewhere. Time based One‑time Passwords (TOTPs) are physical or soft tokens that display a continually changing pseudo‑random one‑time challenge. This type of authentication mechanism is considered "something you have". Multi‑factor TOTPs are similar to single‑factor TOTPs, but require a valid PIN code, biometric unlocking, USB insertion or NFC pairing, or some additional value (such as transaction signing calculators) to be entered to create the final One‑time Password (OTP).
| # | Level | Requirement | Status | How We Comply | What to Do |
|---|---|---|---|---|---|
| 6.5.1 | 2 | Verify that lookup secrets, out‑of‑band authentication requests or codes, and time‑based one‑time passwords (TOTPs) are only successfully usable once. | Out of scope | MFA not yet implemented. These requirements apply when MFA is added. | — |
| 6.5.2 | 2 | Verify that, when being stored in the application's backend, lookup secrets with less than 112 bits of entropy (19 random alphanumeric characters or 34 random digits) are 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. | Out of scope | MFA not yet implemented. These requirements apply when MFA is added. | — |
| 6.5.3 | 2 | Verify that lookup secrets, out‑of‑band authentication code, and time‑based one‑time password seeds, are generated using a Cryptographically Secure Pseudorandom Number Generator (CSPRNG) to avoid predictable values. | Out of scope | MFA not yet implemented. These requirements apply when MFA is added. | — |
| 6.5.4 | 2 | Verify that lookup secrets and out‑of‑band authentication codes have a minimum of 20 bits of entropy (typically 4 random alphanumeric characters or 6 random digits is sufficient). | Out of scope | MFA not yet implemented. These requirements apply when MFA is added. | — |
| 6.5.5 | 2 | Verify that out‑of‑band authentication requests, codes, or tokens, as well as time‑based one‑time passwords (TOTPs) 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. | Out of scope | MFA not yet implemented. These requirements apply when MFA is added. | — |
| 6.5.6 | 3 | Verify that any authentication factor (including physical devices) can be revoked in case of theft or other loss. | |||
| 6.5.7 | 3 | Verify that biometric authentication mechanisms are only used as secondary factors together with either something you have or something you know. | |||
| 6.5.8 | 3 | Verify that time‑based one‑time passwords (TOTPs) are checked based on a time source from a trusted service and not from an untrusted or client provided time. |
This usually involves the authentication server communicating with a physical device over a secure secondary channel. For example, sending push notifications to mobile devices. This type of authen‑ tication mechanism is considered "something you have". Unsafe out‑of‑band authentication mechanisms such as e‑mail and VOIP are not permitted. PSTN and SMS authentication are currently considered to be "restricted"authentication mechanisms by
| # | Level | Requirement | Status | How We Comply | What to Do |
|---|---|---|---|---|---|
| 6.6.1 | 2 | Verify that authentication mechanisms using the Public Switched Telephone Network (PSTN) to deliver One‑time Passwords (OTPs) via phone or SMS are 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 L3 applications, phone and SMS must not be available as options. | Out of scope | MFA not yet implemented. These requirements apply when MFA is added. | — |
| 6.6.2 | 2 | Verify that out‑of‑band authentication requests, codes, or tokens are bound to the original authentication request for which they were generated and are not usable for a previous or subsequent one. | Out of scope | MFA not yet implemented. These requirements apply when MFA is added. | — |
| 6.6.3 | 2 | Verify that a code based out‑of‑band authentication mechanism is protected against brute force attacks by using rate limiting. Consider also using a code with at least 64 bits of entropy. | Out of scope | MFA not yet implemented. These requirements apply when MFA is added. | — |
| 6.6.4 | 3 | Verify that, where push notifications are used for multi‑factor authentication, rate limiting is used to prevent push bombing attacks. Number matching may also mitigate this risk. |
Cryptographic authentication mechanisms include smart cards or FIDO keys, where the user has to plug in or pair the cryptographic device to the computer to complete authentication. The authenti‑ cation server will send a challenge nonce to the cryptographic device or software, and the device or software calculates a response based upon a securely stored cryptographic key. The requirements in this section provide implementation‑specific guidance for these mechanisms, with guidance on cryptographic algorithms being covered in the "Cryptography"chapter. Where shared or secret keys are used for cryptographic authentication, these should be stored using the same mechanisms as other system secrets, as documented in the "Secret Management"section in the "Configuration"chapter. The requirements in this section mostly relate to § 5.1.7.2 of NIST's Guidance.
| # | Level | Requirement | Status | How We Comply | What to Do |
|---|---|---|---|---|---|
| 6.7.1 | 3 | Verify that the certificates used to verify cryptographic authentication assertions are stored in a way protects them from modification. | |||
| 6.7.2 | 3 | Verify that the challenge nonce is at least 64 bits in length, and statistically unique or unique over the lifetime of the cryptographic device. |
Identity Providers (IdPs) provide federated identity for users. Users will often have more than one identity with multiple IdPs, such as an enterprise identity using Azure AD, Okta, Ping Identity, or Google, or consumer identity using Facebook, Twitter, Google, or WeChat, to name just a few com‑ mon alternatives. This list is not an endorsement of these companies or services, but simply an encouragement for developers to consider the reality that many users have many established identi‑ ties. Organizations should consider integrating with existing user identities, as per the risk profile of the IdP's strength of identity proofing. For example, it is unlikely a government organization would accept a social media identity as a login for sensitive systems, as it is easy to create fake or throw‑ away identities, whereas a mobile game company may well need to integrate with major social media platforms to grow their active player base. Secure use of external identity providers requires careful configuration and verification to prevent identity spoofing or forged assertions. This section provides requirements to address these risks.
| # | Level | Requirement | Status | How We Comply | What to Do |
|---|---|---|---|---|---|
| 6.8.1 | 2 | Verify that, if the application supports multiple identity providers (IdPs), the user's identity cannot be spoofed via another supported identity provider (eg. by using the same user identifier). The standard mitigation would be 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. | Out of scope | Application does not use external identity providers. | — |
| 6.8.2 | 2 | Verify that the presence and integrity of digital signatures on authentication assertions (for example on JWTs or SAML assertions) are always validated, rejecting any assertions that are unsigned or have invalid signatures. | Out of scope | Application does not use external identity providers. | — |
| 6.8.3 | 2 | Verify that SAML assertions are uniquely processed and used only once within the validity period to prevent replay attacks. | Out of scope | Application does not use external identity providers. | — |
| 6.8.4 | 2 | Verify that, if an application uses a separate Identity Provider (IdP) and expects specific authentication strength, methods, or recentness for specific functions, the application verifies 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). | Out of scope | Application does not use external identity providers. | — |
Total requirements in this chapter: 47
- Level 1: 13
- Level 2: 22
- Level 3: 12