Authenticating users¶
When authenticating users to your application, you should always use tried and tested systems, frameworks, standards and libraries. Authentication is a complex problem with domain experts who solve those problems so you don't have to.
With that in mind, DfE does also have a centralised Identity Provider (DfE-SignIn) - if you require users to login to your application, don't want to have to deal with building authentication yourself then you should use DfE-SignIn.
Password security should closely align with NCSC guidance on the updated approach.
| # | Description | ASVS |
|---|---|---|
| AU1.0.1 | Use SSO wherever possible - such as DfE SignIn or Azure Entra ID. | 2.1 |
| AU1.0.2 | Use Role-Based Access Control (RBAC) and managed identities where it is reasonable to do so to enforce the principle of least privilege and to limit the need for secrets/tokens/passwords. | n/a |
| AU1.0.3 | Check passwords against a deny list. | 2.1 |
| AU1.0.4 | Ensure passwords have a minimum length (such as 12 character minimums). | 2.1 |
| AU1.0.5 | Turn off password expiries (where there is a sufficient minimum length). | 2.1 |
| AU1.0.6 | Turn off complexity rules. | 2.1 |
| AU1.0.7 | Protect passwords in transit by encrypting traffic with HTTPS using secure cipher suites and protocols. | 2.1 |
| AU1.0.8 | Protect passwords at rest by using a hash function that follows public standards such as PBKDF2 and adding an additional "salt" to a password that is at least 32 bits in length before hashing | 2.1 |
| AU1.0.9 | Ensure there is separation and extra security around higher privileged accounts - ideally Just-In-Time (JIT) method of authentication is used. | 2.1 |
| AU1.0.10 | Provide the ability for users to change their passwords securely. | 2.1 |
| AU1.0.11 | Ensure that "paste" functionality is permitted to allow users to use password managers. | 2.1 |
| AU1.0.12 | Implement anti-automation controls to mitigate brute force attacks and breached credentials testing, this could include: - blocking breached passwords - locking accounts after 5-10 failed attempts for a limited time (1 hour+) - rate limiting requests - such as via the WAF/CDN - increasing delays after failed attempts, such as increasing the amount of time an account is locked out if they continue to fail to login after the initial 1 hour lockout is up |
2.1 |
| AU1.0.13 | Ensure that weak authentication methods such as magic links and SMS are not used as the primary authentication method. | 2.1 |
| AU1.0.14 | Verify that secure notifications are sent to users after updates to their authentication details and profile are made or a login happens from an unknown or risky location. | 2.1 |
| AU1.0.15 | Provide a second factor for authentication after a password is entered such as: - One Time Passwords via SMS (OTP) - Time-Based One Time Passwords (TOTP) - hardware tokens - passkeys |
2.1 |
| AU1.0.16 | Where MFA is set up, provide the user with recovery codes after setting them up to enable them to recover an account should they lose access to the second factor. | 2.1 |
| AU1.0.17 | Where forgotten password functionality is used, ensure that any MFA on the account is verified first in order to protect against a bypass. | 2.5 |
| AU1.0.18 | Ensure OTPs are time-limited and one time use. | 2.8 |
| AU1.0.19 | Never reveal session tokens or any other key or token in a URL. | 3.1 |
| AU1.0.20 | When transmitting sensitive data or parameters in a request, always send them in the body of a POST/PUT request, never in the parameters for a GET request. | 3.1 |
| AU1.0.21 | Always create a new session token on user authentication. | 3.2 |
| AU1.0.22 | Verify that the minimum entropy for a session token is at least 64 bits and that an appropriate cryptographic algorithm is used for generation. | 3.2 |
| AU1.0.23 | Opt for the use of JWT tokens over standard session tokens. | n/a |
| AU1.0.24 | Sign and verify JWT tokens and the claims within using an EdDSA signature algorithm or the ES256 using SHA256, to ensure that tampering is not possible. The aforementioned methods are considered the best balance in terms of security and speed. If neither are supported, then opt for RS256. The server should reject any token that does not contain the signature algorithm used to sign the token, where verification of the signature type should be compared after forcing the value to lowercase. |
3.5 |
| AU1.0.25 | Always ensure that on the user logging out of the application or after the expiration of the token used, that the tokens are invalidated and the session cannot be resumed or authenticated without going through the re-authentication process. | 3.3 |
| AU1.0.26 | Periodically force re-authentication of a user both when actively used or after an idle period based on the risk level of the application and data within. 15 minutes being for the highest risk applications and 12 hours for the lowest risk. Refresh tokens can be used where JWTs are the chosen method. | 3.3 |
| AU1.0.27 | Provide users with the option to terminate all sessions and remove verified devices, terminate all sessions when the password reset functionality is used. | 3.3 |
| AU1.0.28 | Where cookies are used for sessions ensure that the secure attribute, the HTTPOnly attribute and the SameSite attribute are implemented to force cookies to only be transmitted via HTTPS and limit exposure to CSRF attacks. |
3.4 |
| AU1.0.29 | Utilise the __Host- prefix so cookies are only sent to the original host and ensure the the path attribute is set to the most precise path possible to ensure that the cookie is only valid for the specific website it was generated for. |
3.4 |
| AU1.0.30 | Enforce access control rules using backend logic and ensure that controls cannot be manipulated by users. Access control rules must implement the principle of least privilege ensuring that users are only able to access the functions, APIs, data, URLs, services and resources for which they posses explicit authorisation. | 4.1 |
| AU1.0.31 | The application code or web framework must enforce strong anti-CSRF mechanisms to protect unauthenticated functionality, | 4.2 |
| AU1.0.32 | If an administrator interface exists, ensure it has appropriate controls including multi-factor authentication enforcement, longer password minimums, and IP safelisting (if possible). | 4.3 |
| AU1.0.33 | If a traditional web server is in use, ensure that directory browsing is disabled to prevent sensitive file disclosures. | 4.3 |
| AU1.0.34 | If there are specific sensitive functionalities, ensure that additional step-up controls are in place, such as requiring a multi-factor authentication token again before processing the request. | 4.3 |