+V6.3 General Authentication Security
---+V6.3.1 Verify that controls to prevent attacks such as credential stuffing and password brute force are …
---+V6.3.2 Verify that default user accounts (e.g., "root", "admin", or "sa") are not present in the …
---+V6.3.3 Verify that either a multi-factor authentication mechanism or a combination of single-factor …
---+V6.3.4 Verify that, if the application includes multiple authentication pathways, there are no …
---+V6.3.5 Verify that users are notified of suspicious authentication attempts (successful or unsuccessful). …
---+V6.3.6 Verify that email is not used as either a single-factor or multi-factor authentication mechanism.
---+V6.3.7 Verify that users are notified after updates to authentication details, such as credential resets …
---+V6.3.8 Verify that valid users cannot be deduced from failed authentication challenges, such as by basing …

V6.3 General Authentication Security

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 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.

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.

1. Resumen

V6.3.1 Verify that controls to prevent attacks such as credential stuffing and password brute force are …

Verify that controls to prevent attacks such as credential stuffing and password brute force are implemented according to the application's security documentation.
V6.3.2 Verify that default user accounts (e.g., "root", "admin", or "sa") are not present in the …

Verify that default user accounts (e.g., "root", "admin", or "sa") are not present in the application or are disabled.
V6.3.3 Verify that either a multi-factor authentication mechanism or a combination of single-factor …

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.
V6.3.4 Verify that, if the application includes multiple authentication pathways, there are no …

Verify that, if the application includes multiple authentication pathways, there are no undocumented pathways and that security controls and authentication strength are enforced consistently.
V6.3.5 Verify that users are notified of suspicious authentication attempts (successful or unsuccessful). …

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.
V6.3.6 Verify that email is not used as either a single-factor or multi-factor authentication mechanism.

Verify that email is not used as either a single-factor or multi-factor authentication mechanism.
V6.3.7 Verify that users are notified after updates to authentication details, such as credential resets …

Verify that users are notified after updates to authentication details, such as credential resets or modification of the username or email address.
V6.3.8 Verify that valid users cannot be deduced from failed authentication challenges, such as by basing …

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.

1.1 Referencias

1.2 Requisitos identificados

1.3 Regulaciones relacionadas

2. Requisitos identificados

Requisitos

3. Regulaciones relacionadas

Regulaciones
  • OWASP -

    EN: Publications of the OWASP Foundation, https://owasp.org/. OWASP® is a registered trademark of the OWASP Foundation, Inc.; GRCA is not affiliated with, nor endorsed by, the OWASP Foundation. Only the versions published by OWASP are authoritative.

    DE: Veröffentlichungen der OWASP Foundation, https://owasp.org/. OWASP® ist eine eingetragene Marke der OWASP Foundation, Inc.; GRCA steht in keiner Verbindung zur OWASP Foundation und wird von ihr nicht unterstützt. Maßgeblich sind allein die von OWASP veröffentlichten Fassungen.