authelia/docs/content/en/overview/security/threat-model.md

title	description	lead	date	draft	images	menu	weight	toc	aliases
Threat Model	An overview of the Authelia threat model.	An overview of the Authelia threat model.	2020-04-16T18:12:41+10:00	false		overview parent security	430	false	/o/threatmodel /docs/security/threat-model.html

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. Some of these ideas are expanded on or otherwise described in Security Measures.

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 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 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.
• 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).
• Detect credential theft and prevent malicious actions.
• Detect session cookie theft and prevent malicious actions.
• Binding session cookies to single IP addresses.
• Authenticate communication between Authelia and reverse proxy.
• Securely transmit authentication data to backends (OAuth2 with bearer tokens).
• 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).
• 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:

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.