* [FIX] LDAP Not Checking for Updated Groups * refactor handlers verifyFromSessionCookie * refactor authorizer selectMatchingObjectRules * refactor authorizer isDomainMatching * add authorizer URLHasGroupSubjects method * add user provider ProviderType method * update tests * check for new LDAP groups and update session when: * user provider type is LDAP * authorization is forbidden * URL has rule with group subjects * Implement Refresh Interval * add default values for LDAP user provider * add default for refresh interval * add schema validator for refresh interval * add various tests * rename hasUserBeenInactiveLongEnough to hasUserBeenInactiveTooLong * use Authelia ctx clock * add check to determine if user is deleted, if so destroy the * make ldap user not found error a const * implement GetRefreshSettings in mock * Use user not found const with FileProvider * comment exports * use ctx.Clock instead of time pkg * add debug logging * use ptr to reference userSession so we don't have to retrieve it again * add documenation * add check for 0 refresh interval to reduce CPU cost * remove badly copied debug msg * add group change delta message * add SliceStringDelta * refactor ldap refresh to use the new func * improve delta add/remove log message * fix incorrect logic in SliceStringDelta * add tests to SliceStringDelta * add always config option * add tests for always config option * update docs * apply suggestions from code review Co-Authored-By: Amir Zarrinkafsh <nightah@me.com> * complete mocks and fix an old one * show warning when LDAP details failed to update for an unknown reason * golint fix * actually fix existing mocks * use mocks for LDAP refresh testing * use mocks for LDAP refresh testing for both added and removed groups * use test mock to verify disabled refresh behaviour * add information to threat model * add time const for default Unix() value * misc adjustments to mocks * Suggestions from code review * requested changes * update emails * docs updates * test updates * misc * golint fix * set debug for dev testing * misc docs and logging updates * misc grammar/spelling * use built function for VerifyGet * fix reviewdog suggestions * requested changes * Apply suggestions from code review Co-authored-by: Amir Zarrinkafsh <nightah@me.com> Co-authored-by: Clément Michaud <clement.michaud34@gmail.com>
7.0 KiB
layout | title | parent | nav_order |
---|---|---|---|
default | Security Measures | Security | 1 |
Security Measures
Protection against cookie theft
Authelia uses two mechanisms to protect against cookie theft:
- session attribute
httpOnly
set to true make client-side code unable to read the cookie. - session attribute
secure
ensure the cookie will never be sent over an insecure HTTP connections.
Protection against multi-domain cookie attacks
Since Authelia uses multi-domain cookies to perform single sign-on, an attacker who poisoned a user's DNS cache can easily retrieve the user's cookies by making the user send a request to one of the attacker's IPs.
To mitigate this risk, it's advisable to only use HTTPS connections with valid certificates and enforce it with HTTP Strict Transport Security (HSTS) so that the attacker must also require the certificate to retrieve the cookies.
Note that using HSTS has consequences. That's why you should read the blog post nginx has written on HSTS.
Protections against password cracking (File authentication provider)
Authelia implements a variety of measures to prevent an attacker cracking passwords if they somehow obtain the file used by the file authentication provider, this is unrelated to LDAP auth.
First and foremost Authelia only uses very secure hashing algorithms with sane and secure defaults. The first and default hashing algorithm we use is Argon2id which is currently considered the most secure hashing algorithm. We also support SHA512, which previously was the default.
Secondly Authelia uses salting with all hashing algorithms. These salts are generated with a random string generator, which is seeded every time it's used by a cryptographically secure 1024bit prime number. This ensures that even if an attacker obtains the file, each password has to be brute forced individually.
Lastly Authelia's implementation of Argon2id is highly tunable. You can tune the key length, salt used, iterations (time), parallelism, and memory usage. To read more about this please read how to configure file authentication.
User profile and group membership always kept up-to-date (LDAP authentication provider)
Authelia by default refreshes the user's profile and membership every 5 minutes. Additionally, it will invalidate any session where the user could not be retrieved from LDAP based on the user filter, for example if they were deleted or disabled provided the user filter is set correctly. These updates occur when a user accesses a resource protected by Authelia.
These protections can be tuned according to your security policy by changing refresh_interval, however we believe that 5 minutes is a fairly safe interval.
Notifier security measures (SMTP)
By default the SMTP Notifier implementation does not allow connections that are not secure. As such all connections require the following:
- TLS Connection (STARTTLS or SMTPS) has been negotiated before authentication or sending emails (unauthenticated connections require it as well)
- Valid X509 Certificate presented to the client during the TLS handshake
There is an option to disable both of these security measures however they are not recommended. You should only do this in a situation where you control all networks between Authelia and the SMTP server. The following configuration options exist to configure the security level:
SMTPS vs STARTTLS
By default all connections start as plain text and are upgraded via STARTTLS. SMTPS is supported, however due to the fact it was basically considered deprecated before the turn of the century, there is no way to configure it. It happens automatically when a SMTP notifier is configured with the SMTPS port of 465.
Configuration Option: disable_verify_cert
This is a YAML boolean type (true/false, y/n, 1/0, etc). This disables the X509 PKI verification mechanism. We recommend using the trusted_cert option over this, as disabling this security feature makes you vulnerable to MITM attacks.
Configuration Option: disable_require_tls
This is a YAML boolean type (true/false, y/n, 1/0, etc). This disables the requirement that all connections must be over TLS. This is only usable currently with authentication disabled (comment the password) and as such is only an option for SMTP servers that allow unauthenticated relay (bad practice).
Configuration Option: trusted_cert
This is a YAML string type. This specifies the file location of a pub certificate that can be used to validate the authenticity of a server with a self signed certificate. This can either be the public cert of the certificate authority used to sign the certificate or the public key itself. They must be in the PEM format. The certificate is added in addition to the certificates trusted by the host machine. If the certificate is invalid, inaccessible, or is otherwise not configured; Authelia just uses the hosts certificates.
Explanation
There are a few reasons for the security measures implemented:
- Transmitting username's and passwords over plain-text is an obvious vulnerability
- The emails generated by Authelia, if transmitted in plain-text could allow an attacker to intercept a link used to setup 2FA; which reduces security
- Not validating the identity of the server allows man-in-the-middle attacks
Additional security
Reset Password
It's possible to disable the reset password functionality and is recommended for anyone wanting to increase security. See the configuration for information.
Session security
We have a few options to configure the security of a session. The main and most important one is the session secret. This is used to encrypt the session data when when stored in the Redis key value database. This should be as random as possible.
Additionally you can configure the validity period of sessions. For example in a highly security conscious domain you would probably want to set the session remember_me_duration to 0 to disable this feature, and set an expiration of something like 2 hours and inactivity of 10 minutes. This means the hard limit or the time the session will be destroyed no matter what is 2 hours, and the soft limit or the time a user can be inactive for is 10 minutes.
More protections measures with Nginx
You can also apply the following headers to your nginx configuration for improving security. Please read the documentation of those headers before applying them blindly.
# We don't want any credentials / TOTP secret key / QR code to be cached by
# the client
add_header Cache-Control "no-store";
add_header Pragma "no-cache";
# Clickjacking / XSS protection
# We don't want Authelia's login page to be rendered within a <frame>,
# <iframe> or <object> from an external website.
add_header X-Frame-Options "SAMEORIGIN";
# Block pages from loading when they detect reflected XSS attacks.
add_header X-XSS-Protection "1; mode=block";