6b155621fe
* add password policy to default password change flow This change complies with the minimal compositional requirements by NIST SP 800-63 Digital Identity Guidelines. See https://pages.nist.gov/800-63-4/sp800-63b.html#password More work is needed to comply with other parts of the Guidelines, specifically > If the chosen password is found on the blocklist, the CSP or verifier > [...] SHALL provide the reason for rejection. and > Verifiers SHALL offer guidance to the subscriber to assist the user in > choosing a strong password. This is particularly important following > the rejection of a password on the blocklist as it discourages trivial > modification of listed weak passwords. * add docs for default Password policy * remove HIBP from default Password policy * add zxcvbn to default Password policy * add fallback password error message to password policy, fix validation policy Signed-off-by: Jens Langhammer <jens@goauthentik.io> * reword docs Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com> Signed-off-by: Simonyi Gergő <28359278+gergosimonyi@users.noreply.github.com> * add HIBP caveat Co-authored-by: Jens L. <jens@goauthentik.io> Signed-off-by: Simonyi Gergő <28359278+gergosimonyi@users.noreply.github.com> * separate policy into separate blueprint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use password policy for oobe flow Signed-off-by: Jens Langhammer <jens@goauthentik.io> * kiss Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Signed-off-by: Simonyi Gergő <28359278+gergosimonyi@users.noreply.github.com> Co-authored-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com>
3.0 KiB
title
| title |
|---|
| Hardening authentik |
While authentik is secure out of the box, you can take steps to further increase the security of an authentik instance. As everyone knows, there is a consequential tradeoff between security and convenience. All of these hardening practices have an impact on the user experience and should only be applied knowing this tradeoff.
Password policy
authentik's default Password policy complies with the NIST SP 800-63 Digital Identity Guidelines.
However, for further hardening compliant to the NIST Guidelines, consider
- setting the length of the password to a minimum of 15 characters, and
- enabling the "Check haveibeenpwned.com" blocklist comparison (note that this cannot be used on Air-gapped instances)
For further options, see Password policy.
Expressions
Expressions allow super-users and other highly privileged users to create custom logic within authentik to modify its behaviour. Editing/creating these expressions is, by default, limited to super-users and any related events are fully logged.
However, for further hardening, it is possible to prevent any user (even super-users) from using expressions to create or edit any objects. To do so, configure your deployment to block API requests to these endpoints:
/api/v3/policies/expression*/api/v3/propertymappings*/api/v3/managed/blueprints*
With these restrictions in place, expressions can only be edited using Blueprints on the file system. Take care to restrict access to the file system itself.
Blueprints
Blueprints allow for templating and managing the authentik configuration as code. Just like expressions, they can only be created/edited by super-users or users with specific permissions assigned to them. However, because they interact with the authentik API on a lower level, they can create other objects.
To prevent any user from creating/editing blueprints, block API requests to this endpoint:
/api/v3/managed/blueprints*
With these restrictions in place, Blueprints can only be edited via the file system.
CAPTCHA Stage
The CAPTCHA stage allows for additional verification of a user while authenticating or authorising an application. Because the CAPTCHA stage supports multiple different CAPTCHA providers, such as Google’s reCAPTCHA and Cloudflare’s Turnstile, the URL for the JavaScript snippet can be modified. Depending on the threat model, this could be exploited by a malicious internal actor.
To prevent any user from creating/editing CAPTCHA stages block API requests to these endpoints:
/api/v3/stages/captcha*/api/v3/managed/blueprints*
With these restrictions in place, CAPTCHA stages can only be edited using Blueprints on the file system.