SCP [33, 40, 51, 73, 74] Cornucopia - Session Management - Authentication and Passwords #134
Description
These are SCP coding practices used during Cornucopia threat modeling sessions that we could add here.
Session Management
SCP [73] Supplement standard session management for sensitive server-side operations, like account management, by utilizing per-session strong random tokens or parameters. This method can be used to prevent Cross Site Request Forgery attacks (CSRF tokens)
SCP [74] Supplement standard session management for highly sensitive or critical operations by utilizing per-request, as opposed to per-session, strong random tokens or parameters
SCP [73] is referred to in SMX and SMJ.
SCP [74] is referred to in SMX and SMJ.
Suggestion: Supplement standard session management for sensitive server-side operations, like account management, by requiring and validating anti-forgery tokens (CSRF tokens) for each request that may change application state or execute an action.
References:
ASVS 10.2.1 https://github.com/OWASP/ASVS/blob/master/5.0/en/0x19-V10-OAuth-and-OIDC.md#v102-oauth-client
ASVS 3.5.1 https://github.com/OWASP/ASVS/blob/master/5.0/en/0x12-V3-Web-Frontend-Security.md#v35-browser-origin-separation
ASVS 3.3.2 https://github.com/OWASP/ASVS/blob/master/5.0/en/0x12-V3-Web-Frontend-Security.md#v33-cookie-setup
WASTG: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/05-Testing_for_Cross_Site_Request_Forgery
OWASP community: https://owasp.org/www-community/attacks/csrf
Authentication
SCP [33] Authentication failure responses should not indicate which part of the authentication data was incorrect. For example, instead of "Invalid username" or "Invalid password", just use "Invalid username and/or password" for both. Error responses must be truly identical in both display and source code
SCP [33] is referred to in AT4
Suggestion:
- Authentication failure responses should not indicate which part of the authentication data was incorrect.
E.g. Through giving different textual response or HTTP response codes - Authentication failure responses should not give away the existent of user accounts allowing the response time to differ,
depending on whether a username exist or not. Use a DB transaction that looks for a fake user profile in case the username
doesn't exist - Add a random tunable delay for authentication failures to defer brute force attacks and protect against timing attacks
References:
OWASP Community: https://owasp.org/www-community/controls/Blocking_Brute_Force_Attacks
Authentication Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
OWASP Top 10 2021: https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/
Passwords
SCP [40] Password entry should be obscured on the user's screen. (e.g., on web forms use the input type "password")
SCP [40] is referred to in AT3
Suggestion: Password entry should be masked (e.g., on web forms use the input type "password") on the user's screen unless temporarily made viewable by the user
ASVS 6.2.6 https://github.com/OWASP/ASVS/blob/master/5.0/en/0x15-V6-Authentication.md#v62-password-security
SCP [51] AZ3, C4: Disable "remember me" functionality for password fields
SCP [51] is referred to in AZ3 and C4
Suggestion: Ensure that no credentials are stored in clear text or are easily retrievable in encoded or encrypted forms in browser storage mechanisms