|
|
| Line 1: |
Line 1: |
| − | == V2: Authentication Verification Requirements ==
| + | {{taggedDocument |
| − | | + | | type=delete |
| − | === Control Objective === | + | | comment=Tagged via fixme/delete. |
| − | | + | }} |
| − | Authentication is the act of establishing, or confirming, something (or someone) as authentic, that is, that claims made by or about the thing are true. Ensure that a verified application satisfies the following high level requirements:
| |
| − | | |
| − | * Verifies the digital identity of the sender of a communication.
| |
| − | * Ensures that only those authorised are able to authenticate and credentials are transported in a secure manner.
| |
| − | | |
| − | === Security Verification Requirements ===
| |
| − | | |
| − | {| class="wikitable"
| |
| − | ! # !! Description !! L1 !! L2 !! L3 !! Since
| |
| − | |-
| |
| − | | 2.1 || Verify all pages and resources are protected by server-side authentication, except those specifically intended to be public. || ✓ || ✓ || ✓ || 3.1
| |
| − | |-
| |
| − | | 2.2 || Verify that the application does not automatically fill in credentials – either as hidden fields, URL arguments, Ajax requests, or in forms, as this implies plain text, reversible or de-cryptable password storage. Random time limited nonces are acceptable as stand ins, such as to protect change password forms or forgot password forms. || ✓ || ✓ || ✓ || 3.1
| |
| − | |-
| |
| − | | 2.6 || Verify all authentication controls fail securely to ensure attackers cannot log in. || ✓ || ✓ || ✓ || 1.0
| |
| − | |-
| |
| − | | 2.7 || Verify password entry fields allow, or encourage, the use of passphrases, and do not prevent long passphrases or highly complex passwords being entered. || ✓ || ✓ || ✓ || 3.0.1
| |
| − | |-
| |
| − | | 2.8 || Verify all identity functions (e.g. forgot password, change password, change email, manage 2FA token, etc.) have the security controls, as the primary authentication mechanism (e.g. login form). || ✓ || ✓ || ✓ || 2.0
| |
| − | |-
| |
| − | | 2.9 || Verify that the changing password functionality includes the old password, the new password, and a password confirmation. || ✓ || ✓ || ✓ || 1.0
| |
| − | |-
| |
| − | | 2.12 || 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. || || ✓ || ✓ || 3.0.1
| |
| − | |-
| |
| − | | 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. || || ✓ || ✓ || 3.0.1
| |
| − | |-
| |
| − | | 2.16 || Verify that all application data is transmitted over an encrypted channel (e.g. TLS). || ✓ || ✓ || ✓ || 3.1
| |
| − | |-
| |
| − | | 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. A one time password reset link should be used instead. || ✓ || ✓ || ✓ || 2.0
| |
| − | |-
| |
| − | | 2.18 || Verify that information enumeration is not possible via login, password reset, or forgot account functionality. || || ✓ || ✓ || 2.0
| |
| − | |-
| |
| − | | 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.0
| |
| − | |-
| |
| − | | 2.20 || Verify that anti-automation is in place to prevent breached credential testing, brute forcing, and account lockout attacks. || || ✓ || ✓ || 3.0.1
| |
| − | |-
| |
| − | | 2.21 || Verify that all authentication credentials for accessing services external to the application are encrypted and stored in a protected location. || || ✓ || ✓ || 2.0
| |
| − | |-
| |
| − | | 2.22 || Verify that forgotten password and other recovery paths use a TOTP or other soft token, mobile push, or other offline recovery mechanism. The use of SMS has been deprecated by NIST and should not be used. || || ✓ || ✓ || 3.0.1
| |
| − | |-
| |
| − | | 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. || || ✓ || ✓ || 3.0
| |
| − | |-
| |
| − | | 2.24 || Verify that if secret questions are required, the questions do not violate privacy laws and are sufficiently strong to protect accounts from malicious recovery. || ✓ || ✓ || ✓ || 3.0.1
| |
| − | |-
| |
| − | | 2.25 || Verify that high value applications can be configured to disallow the use of a configurable number of previous passwords. || || ✓ || ✓ || 3.1
| |
| − | |-
| |
| − | | 2.26 || Verify that sensitive operations (e.g. change password, change email address, add new biller, etc.) require re-authentication (e.g. password or 2FA token). This is in addition to CSRF measures, not instead. || || ✓ || ✓ || 3.0.1
| |
| − | |-
| |
| − | | 2.27 || Verify that measures are in place to block the use of commonly chosen passwords and weak pass-phrases. || || ✓ || ✓ || 3.0
| |
| − | |-
| |
| − | | 2.28 || Verify that all authentication challenges, whether successful or failed, should respond in the same average response time. || || || ✓ || 3.0
| |
| − | |-
| |
| − | | 2.29 || Verify that secrets, API keys, and passwords are not included in the source code, or online source code repositories. || || ✓ || ✓ || 3.0
| |
| − | |-
| |
| − | | 2.31 || Verify that users can enrol and use TOTP verification, two-factor, biometric (Touch ID or similar), or equivalent multi-factor authentication mechanism that provides protection against single factor credential disclosure. || || ✓ || ✓ || 3.1
| |
| − | |-
| |
| − | | 2.32 || Verify that access to administrative interfaces are strictly controlled and not accessible to untrusted parties. || ✓ || ✓ || ✓ || 3.0
| |
| − | |-
| |
| − | | 2.33 || Verify that the application is compatible with browser based and third party password managers, unless prohibited by risk based policy. || ✓ || ✓ || ✓ || 3.1
| |
| − | |}
| |
| − | | |
| − | === References ===
| |
| − | | |
| − | For more information, see also:
| |
| − | | |
| − | * [https://www.owasp.org/index.php/Testing_for_authentication OWASP Testing Guide 4.0: Testing for Authentication]
| |
| − | * [https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet:Password storage cheat sheet]
| |
| − | * [https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet:Forgot password cheat sheet]
| |
| − | * [https://www.owasp.org/index.php/Choosing_and_Using_Security_Questions_Cheat_SheetChoosing and Using Security Questions at]
| |
