From 1f738fdf684fb4c6fece91b5f51c5a41935edb86 Mon Sep 17 00:00:00 2001 From: sydseter Date: Fri, 4 Jul 2025 12:21:07 +0200 Subject: [PATCH 1/3] Fixes #136 Resort list --- .../06-digital-identity.md | 77 +++++++++---------- 1 file changed, 38 insertions(+), 39 deletions(-) diff --git a/docs/en/04-design/02-web-app-checklist/06-digital-identity.md b/docs/en/04-design/02-web-app-checklist/06-digital-identity.md index d255860c..ca9c3e94 100644 --- a/docs/en/04-design/02-web-app-checklist/06-digital-identity.md +++ b/docs/en/04-design/02-web-app-checklist/06-digital-identity.md @@ -9,53 +9,52 @@ and use the list below as suggestions for a checklist that has been tailored for #### 1. Authentication 1. Design access control authentication thoroughly up-front -2. Force all requests to go through access control checks unless public -3. Do not hard code access controls that are role based -4. Log all access control events -5. Use [Multi-Factor Authentication][csmfa] (MFA) for sensitive or high value transactional accounts -6. Authentication failure responses should not indicate which part of the authentication data was incorrect. +2. Require authentication for all pages and resources, except those specifically intended to be public +3. All authentication controls must be enforced on a trusted system +4. All authentication controls should fail securely +5. Establish and utilize standard, tested, authentication services whenever possible +6. If using third party code for authentication inspect the code carefully + to ensure it is not affected by any malicious code +7. Use a centralized implementation for all authentication controls +8. Segregate authentication logic from the resource being requested and + use redirection to and from the centralized authentication control +9. Administrative and account management must be at least as secure as the primary authentication mechanism +10. Use [Multi-Factor Authentication][csmfa] (MFA) for sensitive or high value transactional accounts +11. Re-authenticate users prior to performing critical operations +12. Enforce account disabling after an established number of invalid login attempts +13. Utilize authentication for connections to external systems that involve sensitive information or functions +14. Authentication credentials for accessing services external to the application should be stored in a secure store +15. Use only HTTP POST requests to transmit authentication credentials +16. Force all requests to go through access control checks unless public +17. Do not hard code access controls that are role based +18. Log all access control events +19. Validate the authentication data only on completion of all data input +20. 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 -7. Authentication failure responses should not give away the existent of user accounts allowing the response time to differ, +21. 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 -8. Add a random tunable delay for authentication failures to defer brute force attacks and protect against timing attacks +22. Add a random tunable delay for authentication failures to defer brute force attacks and protect against timing attacks #### 2. Passwords -1. Require authentication for all pages and resources, except those specifically intended to be public -2. All authentication controls must be enforced on a trusted system -3. Establish and utilize standard, tested, authentication services whenever possible -4. Use a centralized implementation for all authentication controls -5. Segregate authentication logic from the resource being requested and - use redirection to and from the centralized authentication control -6. All authentication controls should fail securely -7. Administrative and account management must be at least as secure as the primary authentication mechanism -8. If your application manages a credential store, use cryptographically strong one-way salted hashes -9. Password hashing must be implemented on a trusted system -10. Validate the authentication data only on completion of all data input -11. Authentication failure responses should not indicate which part of the authentication data was incorrect -12. Utilize authentication for connections to external systems that involve sensitive information or functions -13. Authentication credentials for accessing services external to the application should be stored in a secure store -14. Use only HTTP POST requests to transmit authentication credentials -15. Always send non-temporary passwords over an encrypted connection or as encrypted data -16. Enforce password complexity and length requirements established by policy or regulation -17. Enforce account disabling after an established number of invalid login attempts -18. Password reset and changing operations require the same level of controls as account creation and authentication -19. Password reset questions are deprecated, see [Choosing and Using Security Questions Cheat Sheet][csquestions] as to why -20. If using email based resets, only send email to a pre-registered address with a temporary link/password -21. Temporary passwords and links should have a short expiration time -22. Enforce the changing of temporary passwords on the next use -23. Notify users when a password reset occurs -24. Prevent password re-use -25. The last use (successful or unsuccessful) of a user account should be reported to the user +1. If your application manages a credential store, use cryptographically strong one-way salted hashes +2. Password hashing must be implemented on a trusted system +3. Always send non-temporary passwords over an encrypted connection or as encrypted data +4. Enforce password complexity and length requirements established by policy or regulation +5. Password reset and changing operations require the same level of controls as account creation and authentication +6. Password reset questions are deprecated, see [Choosing and Using Security Questions Cheat Sheet][csquestions] as to why +7. If using email based resets, only send email to a pre-registered address with a temporary link/password +8. Temporary passwords and links should have a short expiration time +9. Enforce the changing of temporary passwords on the next use +10. Notify users when a password reset occurs +11. Prevent password re-use +12. The last use (successful or unsuccessful) of a user account should be reported to the user at their next successful login -26. Change all vendor-supplied default passwords and user IDs or disable the associated accounts -27. Re-authenticate users prior to performing critical operations -28. If using third party code for authentication inspect the code carefully - to ensure it is not affected by any malicious code -29. Password entry should be masked (e.g., on web forms use the input type "password") on the user's screen unless +13. Change all vendor-supplied default passwords and user IDs or disable the associated accounts +14. 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 -30. Ensure that no credentials are stored in clear text or are easily retrievable in encoded or encrypted forms in the +15. Ensure that no credentials are stored in clear text or are easily retrievable in encoded or encrypted forms in the browser's storage mechanisms #### 3. Cryptographic based authentication From 14954b6e0d6f76d3ac2c2c116d7d44c9ddab2939 Mon Sep 17 00:00:00 2001 From: sydseter Date: Fri, 4 Jul 2025 12:28:01 +0200 Subject: [PATCH 2/3] Fixes #136 Add by --- .../04-design/02-web-app-checklist/06-digital-identity.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/en/04-design/02-web-app-checklist/06-digital-identity.md b/docs/en/04-design/02-web-app-checklist/06-digital-identity.md index ca9c3e94..aac01445 100644 --- a/docs/en/04-design/02-web-app-checklist/06-digital-identity.md +++ b/docs/en/04-design/02-web-app-checklist/06-digital-identity.md @@ -31,9 +31,9 @@ and use the list below as suggestions for a checklist that has been tailored for 19. Validate the authentication data only on completion of all data input 20. 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 -21. 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 +21. Authentication failure responses should not give away the existent of user accounts by 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 22. Add a random tunable delay for authentication failures to defer brute force attacks and protect against timing attacks #### 2. Passwords From d21893b5d8127f843b5020e9c125c19d3286f721 Mon Sep 17 00:00:00 2001 From: sydseter Date: Fri, 4 Jul 2025 15:28:45 +0200 Subject: [PATCH 3/3] Fixes #136 linting --- docs/en/04-design/02-web-app-checklist/06-digital-identity.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/04-design/02-web-app-checklist/06-digital-identity.md b/docs/en/04-design/02-web-app-checklist/06-digital-identity.md index aac01445..97c390d4 100644 --- a/docs/en/04-design/02-web-app-checklist/06-digital-identity.md +++ b/docs/en/04-design/02-web-app-checklist/06-digital-identity.md @@ -32,7 +32,7 @@ and use the list below as suggestions for a checklist that has been tailored for 20. 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 21. Authentication failure responses should not give away the existent of user accounts by 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 + 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 22. Add a random tunable delay for authentication failures to defer brute force attacks and protect against timing attacks