RPJosh
/
authelia
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs: refactor and update security (#1944) 

Refactors the secrurity documentation to be up-to-date and conform to our style guidelines. Additionally went over each part and reworded things that needed it.
pull/2051/head
James Elliott 2021-06-01 14:11:33 +10:00 committed by GitHub
parent cef35fadcd
commit 6b3246a6d3
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 256 additions and 169 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

36
SECURITY.md
View File

@ -1,22 +1,22 @@
# Security
Authelia takes security very seriously. We follow the rule of
[responsible disclosure](https://en.wikipedia.org/wiki/Responsible_disclosure), and we
encourage the community to as well.
[responsible disclosure](https://en.wikipedia.org/wiki/Responsible_disclosure), and we urge our community to do so as
well instead of making the vulnerability public. This allows time for the security issue to be patched quickly.
If you discover a vulnerability in Authelia, please first contact one of the maintainers privately
either via [Matrix](#matrix) or [email](#email) as described in the [contact options](#contact-options) below.
If you discover a vulnerability in Authelia, please first contact one of the maintainers privately either via
[Matrix](#matrix), [Discord](#discord), or [email](#email) as described in the [contact options](#contact-options)
below. We urge you not to disclose the bug publicly at least until we've had a chance to fix it.
For details about security measures implemented in Authelia, please follow
this [link](https://www.authelia.com/docs/security/measures.html) and for reading about
the threat model follow this [link](https://www.authelia.com/docs/security/threat-model.html).
For more information about [security](https://www.authelia.com/docs/security/) related matters, please read
[the documentation](https://www.authelia.com/docs/security/).
## Contact Options
### Matrix
Join the [Matrix Room](https://riot.im/app/#/room/#authelia:matrix.org) and locate one of the maintainers.
You can identify them as they are the room administrators. Alternatively you can just ask for one of the
You can identify them as they are the room administrators. Alternatively you can just ask in the channel for one of the
maintainers. Once you've made contact we ask you privately message the maintainer to communicate the vulnerability.
### Discord
@ -29,5 +29,21 @@ and contact a maintainer.
You can contact any of the maintainers for security vulnerability related issues by emailing
[security@authelia.com](mailto:security@authelia.com). This email is strictly reserved for security and vulnerability
disclosure related matters. If you need to contact us for another reason please use [Matrix](#matrix) or
[team@authelia.com](mailto:team@authelia.com).
disclosure related matters. If you need to contact us for any other reason please use
[team@authelia.com](mailto:team@authelia.com) or another [contact option](#contact-options).
## Credit
Users who report bugs will optionally be creditted for the discovery. Both in the
[security advisory](https://github.com/authelia/authelia/security/advisories) and in our all contributors configuration.
## Process
1. User privately reports a potential vulnerability.
2. The maintainers review the report and ascertain if additional information is required.
3. The maintainers reproduce the bug.
4. The bug is patched, and if possible the user reporting te bug is given access to a fixed version or git patch.
5. The fix is confirmed to resolve the vulnerability.
6. The fix is released.
7. The [security advisory](https://github.com/authelia/authelia/security/advisories) is published sometime after users
have had a chance to update.

30
docs/security/index.md
View File

@ -8,27 +8,13 @@ has_children: true
# Security
Authelia takes security very seriously. We follow the rule of
[responsible disclosure](https://en.wikipedia.org/wiki/Responsible_disclosure), and we
encourage the community to as well.
[responsible disclosure](https://en.wikipedia.org/wiki/Responsible_disclosure), and we encourage the community to as
well.
If you discover a vulnerability in Authelia, please first contact one of the maintainers privately
either via [Matrix](#matrix) or [email](#email) as described in the [contact options](#contact-options) below.
***Important:*** Please see our [security policy](https://github.com/authelia/authelia/security/policy) if you discover
a security vulnerability. Our [security policy](https://github.com/authelia/authelia/security/policy) has several
methods of contact and more details about the processes we follow.
For details about security measures implemented in Authelia, please follow
this [link](https://www.authelia.com/docs/security/measures.html) and for reading about
the threat model follow this [link](https://www.authelia.com/docs/security/threat-model.html).
## Contact Options
### Matrix
Join the [Matrix Room](https://riot.im/app/#/room/#authelia:matrix.org) and locate one of the maintainers.
You can identify them as they are the room administrators. Alternatively you can just ask for one of the
maintainers. Once you've made contact we ask you privately message the maintainer to communicate the vulnerability.
### Email
You can contact any of the maintainers for security vulnerability related issues by emailing
[security@authelia.com](mailto:security@authelia.com). This email is strictly reserved for security and vulnerability
disclosure related matters. If you need to contact us for another reason please use [Matrix](#matrix) or
[team@authelia.com](mailto:security@authelia.com).
For details about security measures implemented in Authelia, please follow this
[link](https://www.authelia.com/docs/security/measures.html) and for reading about the threat model follow this
[link](https://www.authelia.com/docs/security/threat-model.html).

279
docs/security/measures.md
View File

@ -19,132 +19,148 @@ Read about these attributes in detail on the
## 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.
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.
This is technically mitigated by the `Secure` attribute set in cookies by Authelia, however it's still advisable to
only use HTTPS connections with valid certificates and enforce it with HTTP Strict Transport Security ([HSTS]) which
will prevent domains from serving over HTTP at all as long as the user has visited the domain before. This means even
if the attacker poisons DNS they are unable to get modern browsers to connect to a compromised host unless they can also
obtain the certificate.
Note that using [HSTS] has consequences. That's why you should read the blog
post nginx has written on [HSTS].
Note that using [HSTS] has consequences. That's why you should read the blog post nginx has written on [HSTS].
## Protection against username enumeration
Authelia adaptively delays authentication attempts based on the mean (average) of the
previous 10 successful attempts, and a small random interval to make it even harder to
determine if the attempt was successful. On start it is assumed that the last 10 attempts
took 1000ms, this quickly grows or shrinks to the correct value over time regardless of the
authentication backend.
Authelia adaptively delays authentication attempts based on the mean (average) of the previous 10 successful attempts
in addition to a small random interval of time. The result of this delay is that it makes it incredibly difficult to
determine if the unsuccessful login was the result of a bad password, a bad username, or both. The random interval of
time is anything between 0 milliseconds and 85 milliseconds.
The cost of this is low since in the instance of a user not existing it just sleeps to delay
the login. Lastly the absolute minimum time authentication can take is 250ms. Both of these measures
also have the added effect of creating an additional delay for all authentication attempts reducing
the likelihood a password can be brute-forced even if regulation settings are too permissive.
When Authelia first starts it assumes the last 10 attempts took 1000 milliseconds each. As users login successfully it
quickly adjusts to the actual time the login attempts take. This process is independent of the login backend you have
configured.
The cost of this is low since in the instance of a user not existing it just stops processing the request to delay the
login. Lastly the absolute minimum time authentication can take is 250 milliseconds. Both of these measures also have
the added effect of creating an additional delay for all authentication attempts increasing the time that a brute-force
attack will take, this combined with regulation greatly delays brute-force attacks and the effectiveness of them in
general.
## 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.
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.
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.
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
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](../configuration/authentication/file.md) 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.
This measure is unrelated to the File authentication provider.
These protections can be [tuned](../configuration/authentication/ldap.md) according to your security policy
by changing refresh_interval, however we believe that 5 minutes is a fairly safe interval.
Authelia by default refreshes the user's profile and membership every 5 minutes. This ensures that if you alter a users
groups in LDAP that their new groups are obtained relatively quickly in order to adjust their access level for
applications secured by Authelia.
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. This means you should ensure disabled users or users with expired passwords
are not obtainable using the LDAP filter, the default filter for Active Directory implements this behaviour.
LDAP implementations vary, so please ask if you need some assistance in configuring this.
These protections can be [tuned](../configuration/authentication/ldap.md#refresh-interval) 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:
The SMTP Notifier implementation does not allow connections that are not secure without changing default configuration
values.
As such all SMTP connections require the following:
1. TLS Connection (STARTTLS or SMTPS) has been negotiated before authentication or sending emails (unauthenticated
connections require it as well)
2. 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:
There is an option to disable both of these security measures however they are **not recommended**.
### SMTPS vs STARTTLS
The following configuration options exist to configure the security level in order of most preferable to least
preferable:
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: certificates_directory
### Configuration Option: disable_verify_cert
You can [configure a directory](../configuration/miscellaneous.md#certificates_directory) of certificates for Authelia
to trust. These certificates can either be CA's or individual public certificates that should be trusted. These
are added in addition to the environments PKI trusted certificates if available. This is useful for trusting a
certificate that is self-signed without drastically reducing security. This is the most recommended workaround to not
having a valid PKI trusted certificate as it gives you complete control over which ones are trusted without disabling
critically needed validation of the identity of the target service.
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.
Read more in the [documentation](../configuration/miscellaneous.md#certificates_directory) for this option.
### Configuration Option: tls.skip_verify
The [tls.skip_verify](../configuration/notifier/smtp.md#tls) option allows you to skip verifying the certificate
entirely which is why [certificates_directory](#configuration-option-certificates_directory) is preferred over this.
This will effectively mean you cannot be sure the certificate is valid which means an attacker via DNS poisoning or MITM
attacks could intercept emails from Authelia compromising a user's security without their knowledge.
### 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).
Authelia by default ensures that the SMTP server connection is secured via STARTTLS or SMTPS prior to sending sensitive
information. The [disable_require_tls](../configuration/notifier/smtp.md#disable_require_tls) disables this requirement
which means the emails are sent in plain text. This is the least secure option as it effectively removes the validation
of SMTP certificates and removes the encryption offered by the STARTTLS/SMTPS connection all together.
### Configuration Option: trusted_cert
This means not only can the vulnerabilities of the [skip_verify](#configuration-option-tlsskip_verify) option be
exploited, but any router or switch along the route of the email which receives the packets could be used to silently
exploit the plain text nature of the email. This is only usable currently with authentication disabled (comment out the
password) and as such is only an option for SMTP servers that allow unauthenticated relay (bad practice).
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.
### SMTPS vs STARTTLS
### Explanation
There are a few reasons for the security measures implemented:
1. Transmitting username's and passwords over plain-text is an obvious vulnerability
2. 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
3. Not validating the identity of the server allows man-in-the-middle attacks
All connections start as plain text and are upgraded via STARTTLS. SMTPS is an exception to this rule where the
connection is over TLS. As SMTPS is deprecated, the only way to configure this is to set the SMTP
[port](../configuration/notifier/smtp.md#port) to the officially recognized SMTPS port of 465 which will cause Authelia
to automatically consider it to be a SMTPS connection. As such your SMTP server, if not offering SMTPS, should not be
listening on port 465 which is bad practice anyway.
## 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](../configuration/authentication/index.md)
for information.
It's possible to disable the reset password functionality and is an optional adjustment to consider for anyone wanting
to increase security. See the [configuration](../configuration/authentication/index.md#disable_reset_password) for more
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.
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 it is stored in the [Redis](../configuration/session/redis.md) key value
database. The value of this option should be long and as random as possible. See more in the
[documentation](../configuration/session/index.md#secret) for this option.
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.
The validity period of session is highly configurable. For example in a highly security conscious domain you could
set the session [remember_me_duration](../configuration/session/index.md#remember_me_duration) to 0 to disable this
feature, and set the [expiration](../configuration/session/index.md#expiration) to 2 hours and the
[inactivity](../configuration/session/index.md#inactivity) of 10 minutes. Configuring the session security in this
manner would mean if the cookie age was more than 2 hours or if the user was inactive for more than 10 minutes the
session would be destroyed.
### Additional proxy protection measures
You can also apply the following headers to your proxy configuration for
improving security. Please read the documentation of those headers before
applying them blindly.
You can also apply the following headers to your proxy configuration for improving security. Please read the
relevant documentation for these headers before applying them blindly.
#### nginx
@ -215,11 +231,13 @@ services:
### More protections measures with fail2ban
If you are running fail2ban, adding a filter and jail for Authelia can reduce load on the application / web server. Fail2ban will ban IPs exceeding a threshold of repeated failed logins at the firewall level of your host.
If you are running fail2ban, adding a filter and jail for Authelia can reduce load on the application / web server.
Fail2ban will ban IPs exceeding a threshold of repeated failed logins at the firewall level of your host. If you are
using Docker, the Authelia log file location has to be mounted from the host system to the container for
fail2ban to access it.
If you are using Docker, the Authelia log file location has to be mounted from the host system to the container for fail2ban to access it.
Create a configuration file in the `filter.d` folder with the content below. In Debian-based systems the folder is typically located at `/etc/fail2ban/filter.d`.
Create a configuration file in the `filter.d` folder with the content below. In Debian-based systems the folder is
typically located at `/etc/fail2ban/filter.d`.
```
# Fail2Ban filter for Authelia
@ -229,7 +247,7 @@ Create a configuration file in the `filter.d` folder with the content below. In
# (it is misleading: usually, this is the purpose of this header).
# the failregex rule counts every failed login (wrong username or password) and failed TOTP entry as a failure
# the ignoreregex rule ignores debug, info and warning messages as all authentication failures are flagged as level=error by Authelia
# the ignoreregex rule ignores debug, info and warning messages as all authentication failures are flagged as errors
[Definition]
failregex = ^.*Error while checking password for.*remote_ip=<HOST> stack.*
@ -241,8 +259,10 @@ ignoreregex = ^.*level=debug.*
^.*level=warning.*
```
Modify the `jail.local` file. In Debian-based systems the folder is typically located at `/etc/fail2ban/`. If the file does not exist, create it by copying the jail.conf `cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local`.
Add an Authelia entry to the "Jails" section of the file:
Modify the `jail.local` file. In Debian-based systems the folder is typically located at `/etc/fail2ban/`. If the file
does not exist, create it by copying the jail.conf `cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local`. Add an
Authelia entry to the "Jails" section of the file:
```
[authelia]
enabled = true
@ -254,55 +274,89 @@ bantime = 1d
findtime = 1d
chain = DOCKER-USER
```
If you are not using Docker remove the the line "chain = DOCKER-USER"
Finally, restart the fail2ban service.
If you are not using Docker remove the line "chain = DOCKER-USER". You will need to restart the fail2ban service for the
changes to take effect.
## Container privilege de-escalation
Authelia will run as root by default, there are two options to run as a non-root user. The first option is to use the
Docker `--user` option on the command line or in docker-compose. The second option is to use the `PUID` and `PGID`
environment variables. An added benefit of using the environment variables is the mounted volumes ownership will automatically
be changed for you.
Authelia will run as the root user and group by default, there are two options available to run as a non-root user and
group.
### Docker user option
It is recommended which ever approach you take that to secure the sensitive files Authelia requires access to that you
make sure the chmod of the files does not inadvertently allow read access to the files by users who do not need access
to them.
With the Docker `--user` option, Docker will ensure Authelia is running as the user id and group id you specify.
In order to use this option, you will need to mount the `/config` volume to a directory on the host and set
the owner and group of that directory to the same user you supplied to docker. Running Authelia with `--user`
without mounting a volume to `/config` or incorrectly setting the host systems directory owner will cause Authelia
to exit immediately. The docker `--user` option will take precedence over the environment variables.
Examples:
On the command line, you would create your Authelia data directory, change ownership to your non-root user
and run Authelia with `--user` set:
```
mkdir /authelia
chown user:group /authelia
docker run --user user:group -v /authelia:/config authelia/authelia:latest
If you wanted to run Authelia as UID 8000, and wanted the GID of 9000 to also have read access to the files
you might do the following assuming the files were in the relative path `.data/authelia`:
```shell
chown -r 8000:9000 .data/authelia
find .data/authelia/ -type d -exec chmod 750 {} \;
find .data/authelia/ -type f -exec chmod 640 {} \;
```
As a docker-compose.yml file:
If you wanted to run Authelia as UID 8000, and wanted the GID of 9000 to also have write access to the files
you might do the following assuming the files were in the relative path `.data/authelia`:
```shell
chown -r 8000:9000 .data/authelia
find .data/authelia/ -type d -exec chmod 770 {} \;
find .data/authelia/ -type f -exec chmod 660 {} \;
```
### Docker user directive
The docker user directive allows you to configure the user the entrypoint runs as. This is generally the most secure
option for containers as no process accessible to the container ever runs as root which prevents a compromised container
from exploiting unnecessary privileges.
The directive can either be applied in your `docker run` command using the `--user` argument or by
the docker-compose `user:` key. The examples below assume you'd like to run the container as UID 8000 and GID 9000.
Example for the docker CLI:
```shell
docker run --user 8000:9000 -v /authelia:/config authelia/authelia:latest
```
Example for docker-compose:
```
version: '3.8'
services:
authelia:
image: authelia/authelia
container_name: authelia
user: 1000:1000
user: 8000:9000
volumes:
- ./authelia:/config
```
### PUID/PGID environment variables
Running the container in this way requires that you manually adjust the file owner at the very least as described above.
If you do not do so it will likely cause Authelia to exit immediately. This option takes precedence over the PUID and
PGID environment variables below, so if you use it then changing the PUID and PGID have zero effect.
If you choose to use the environment variables, the correct ownership will be applied automatically on startup of
the container, so there's no need to `chown` before running, to use this on the command line use the following:
### PUID/PGID environment variables using the entrypoint
```
docker run -e PUID=1000 -e PGID=1000 -v /authelia:/config authelia:authelia:latest
The second option is to use the `PUID` and `PGID` environment variables. When the container entrypoint is executed
as root, the entrypoint automatically runs the Authelia process as this user. An added benefit of using the environment
variables is the mounted volumes ownership will automatically be changed for you. It is still recommended that
you run the find chmod examples above in order to secure the files even further especially on servers multiple people
have access to.
The examples below assume you'd like to run the container as UID 8000 and GID 9000.
Example for the docker CLI:
```shell
docker run -e PUID=1000 -e PGID=1000 -v /authelia:/config authelia/authelia:latest
```
As a docker-compose.yml file:
Example for docker-compose:
```
version: '3.8'
services:
@ -316,5 +370,4 @@ services:
- ./authelia:/config
```
[HSTS]: https://www.nginx.com/blog/http-strict-transport-security-hsts-and-nginx/

74
docs/security/threat-model.md
View File

@ -8,44 +8,76 @@ nav_order: 2
# Threat Model
The design goals for Authelia is to protect access to applications by collaborating with reverse proxies to prevent
attacks coming from the edge of the network. This document gives an overview of what Authelia is protecting against but some
of those points are also detailed in [Security Measures](./measures.md).
attacks coming from the edge of the network. This document gives an overview of what Authelia is protecting against.
Some of these ideas are expanded on or otherwise described in [Security Measures](./measures.md).
## General assumptions
Authelia is considered to be running within a trusted network and it heavily relies on the first level of security provided by reverse proxies. It's very important that you take time configuring your reverse proxy properly to get all the authentication benefits brought by Authelia.
Some general security tweaks are listed in [Security Measures](./measures.md) to give you some ideas.
Authelia is considered to be running within a trusted network and it heavily relies on the first level of security
provided by reverse proxies. It's very important that you take time configuring your reverse proxy properly to get all
the authentication benefits brought by Authelia.
Some general security tweaks are listed in [Security Measures](./measures.md#additional-proxy-protection-measures) to
give you some ideas.
## Guarantees
If properly configured, Authelia guarantees the following for security of your users and your apps:
* Applications cannot be accessed without proper authorization. The access control list is highly configurable allowing administrators to guarantee least privilege principle.
* Applications can be protected with two factors in order to fight against credentials theft and protect highly sensitive data or operations.
* Sessions are bound in time, limiting the impact of a cookie theft. Sessions can have both soft and hard limits. With soft limit, the user is logged out when inactive for a certain period. With hard limit, the user has to authenticate again after a certain period, whether they were active or not.
* Brute force attacks against credentials are protected thanks to a regulation mechanism temporarily blocking the user account after too many attempts.
* Identity validation is required for performing administrative actions such as registering 2FA devices, preventing attackers to pass second factor by auto-registering their own 2FA device. An email with a link is sent to the user and a click is required to confirm the action.
* Applications cannot be accessed without proper authorization. The access control list is highly configurable allowing
administrators to guarantee the least privilege principle.
* Applications can be protected with two-factor authentication in order to fight against credential theft and protect
highly sensitive data or operations.
* Sessions are bound in time, limiting the impact of a cookie theft. Sessions can have both soft and hard expiration
time limits. With the soft limit, the user is logged out when inactive for a certain period of time. With the hard
limit, the user has to authenticate again after a certain period of time, whether they were active or not.
* Brute force attacks against credentials are protected thanks to a regulation mechanism temporarily blocking the user
account after too many attempts and delays to the authentication process.
* Identity validation is required for performing administrative actions such as registering 2FA devices, preventing
attackers to pass two-factor authentication by self-registering their own device. An email with a link is sent to the
user with a link providing them access to the registration flow which can only be opened by a single session.
* Prevention against session fixation by regenerating a new session after each privilege elevation.
* Prevention against LDAP injection by following OWASP recommendations regarding valid input characters (https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html).
* Connections between Authelia and thirdparty components like mail server, database, cache and LDAP server can be made over TLS to protect against man-in-the-middle attacks from within the infrastructure.
* Validation of user session group memberships gets refreshed regularly from the authentication backend (LDAP only).
* Prevention against LDAP injection by following
[OWASP recommendations](https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html)
regarding valid input characters.
* Connections between Authelia and third-party components like the SMTP server, database, session cache, and LDAP server
can be made over TLS to mitigate against man-in-the-middle attacks.
* Validation of user group memberships gets refreshed regularly from the authentication backend (LDAP only).
## Potential future guarantees
* Define and enforce a password policy (to be designed since such a policy can clash with a policy set by the LDAP server).
* Define and enforce a password policy (to be designed since such a policy can clash with a policy set by the LDAP
server).
* Detect credential theft and prevent malicious actions.
* Detect session cookie theft and prevent malicious actions.
* Authenticate communications between Authelia and reverse proxy.
* Binding session cookies to single IP addresses.
* Authenticate communication between Authelia and reverse proxy.
* Securely transmit authentication data to backends (OAuth2 with bearer tokens).
* Protect secrets stored in DB with encryption to prevent secrets leak by DB exfiltration.
* Least privilege on LDAP binding operations (currently administrative user is used to bind while it could be anonymous).
* Protect secrets stored in the database with encryption to prevent secrets leak by database exfiltration.
* Least privilege on LDAP binding operations (currently administrative user is used to bind while it could be anonymous
for most operations).
* Extend the check of user group memberships to authentication backends other than LDAP (File currently).
* Invalidate user session after profile or membership has changed in order to drop remaining privileges on the fly.
* Allow administrators to configure policies regarding password resets so a compromised email account does not leave
accounts vulnerable.
* Allow users to view their active and past sessions to either destroy them, report malicious activity to the
administrator, or both.
* Allow administrators to temporarily restrict users that are suspected of being compromised no matter which backend is
being used.
* Log comprehensive information about user sessions so administrators can identify malicious activity and potential
consequences or damage caused by identified malicious activity.
* Ensure the X-Forwarded-* and X-Original-* headers are able to be trusted by allowing configuration of trusted proxy
servers.
## Trusted environment
It's important to note that Authelia is considered running in a trusted environment for two reasons
It's important to note that Authelia is considered running in a trusted environment for two reasons:
1. Requests coming to Authelia should be initiated by reverse proxies but CAN be initiated by any other server currently. There is no trusted relationship between Authelia and the reverse proxy so an attacker within the network could abuse Authelia and attack it.
2. Your environment should be considered trusted especially if you're using the `Remote-User`, `Remote-Name`, `Remote-Email` and `Remote-Groups` headers to forward authentication data to your backends. These headers are transmitted plain and unsigned to the backends, meaning a malicious user within the network could pretend to be Authelia and send those headers to bypass authentication and gain access to the service. A mitigation could be to transmit those headers with a digital signature which could be verified by the backend however, many backends just don't support it. It has therefore been decided to invest on OpenID Connect instead to solve that authentication delegation problem. Indeed, many backends
do support OAuth2 though since it has become a standard lately.
1. Requests coming to Authelia should be initiated by reverse proxies but CAN be initiated by any other server
currently. There is no trusted relationship between Authelia and the reverse proxy so an attacker within the network
could abuse Authelia and attack it.
2. Your environment should be considered trusted especially if you're using the `Remote-User`, `Remote-Name`,
`Remote-Email` and `Remote-Groups` headers to forward authentication data to your backends. These headers are
transmitted unsigned to the backends, meaning a malicious user within the network could pretend to be
Authelia and send those headers to bypass authentication and gain access to the service. This could be mitigated by
transmitting those headers with a digital signature which could be verified by the backend however, many backends
just won't support it. It has therefore been decided to invest in OpenID Connect instead to solve that authentication
delegation problem.