As an administrator of an Alfresco system, I want it to be difficult to brute-force a user's password on the Alfresco content platform in its default configuration ("out-of-the-box").
Currently, there is nothing preventing a hacker from running through a dictionary of common passwords extremely quickly in order to gain access to the Alfresco system once a user id is known (or guessed). The best way to mitigate this type of attack is to implement traffic protection in the network outside of Alfresco (such as a tarpit on the web gateway) or to use an advanced Identity Provider with the SAML module to leverage additional security. But the repository should be robust against these types of attacks in its default configuration so that customers who do not know how to implement additional protections are as secure as possible.
- After a number of incorrect authentication requests for any given user id, the user id becomes "protected".
- Once marked as protected, a user id stays protected until a correct authentication request is processed.
- While a user id is protected, the platform only allows authentication requests on a predetermined rate-limited schedule. Authentication requests occurring more frequently than the permitted schedule are denied.
- Once a user id is protected, the schedule should cause a six second delay between allowed login attempts.
- When a user id is marked as "protected",
eachthe next login attempt that is denied due to rate limiting generates a message in the Alfresco log file with a priority of WARN (only once).
- The logs should not contain any sensible data like username or password, see REPO-1471. It is better to look up the node id of the person and show it.
- Details of these log messages are described in the user documentation in sufficient detail for an admin to monitor for their occurrence.
- There is a property for enabling or disabling the login protection. It is configurable via a property in alfresco-global.properties, or through JMX. It is enabled by default. This property is documented.
- There is a property for configuring how many incorrect attempts will trigger the protected mode on an account. It is configurable via a property in alfresco-global.properties, or through JMX. It's default is 10 attempts. This property is documented.
- Automated tests exist for this behavior.
- The implementation is done in a manner that does not leave the repository susceptible to a DOS attack.
- The rate limiting algorithms does not need to be configurable.
- There is no need to show to the user when their account is in protected mode.
- Although nice to have, in a clustered environment there is no requirement for the "incorrect login count" to be consistent across the cluster. For example, in a two-node cluster it would be acceptable for each node to independently count five sequential failed authentication attempts, potentially meaning that the cluster doesn't reach full "protected" mode until ten sequential failed authentication requests have occurred for a given user id.
- The limiting mechanism should not be applied to ticket based authentication. In order to guess a ticket the attacker should be able to do a lot of guesses (ticket is random and expire).
- The limiting mechanism should be applied only to username/password based authentication. In case of external authentication it is not possible to limit the logins as the user in the header is already supposed to be trusted.
- It is confusing for a legitimate user to not be able to log in. It is especially confusing if their login is denied when they are using a correct password. Ideally, they would know if they are subject to rate limiting and know when they can log in next.
- The user interacts with the repository across various interfaces, and there is no consistent way to inform the user when their account is being protected and so is subject to rate-limiting of login attempts.
- Any attempt to inform the user of the system behavior also informs an attacker of the defenses we have implemented.
- Denying access to legitimate users can be as costly to a business as a system compromise.
- Slowing down the rate of logins could occupy system threads and leave the system vulnerable to denial of service attacks.
In order to strike the correct balance of these concerns:
- Administrators can disable the functionality if their users are confused by the behavior, or if the administrator deems the risk of locking out a legitimate user to be too high.
- An administrator can set the threshold for protecting an account high enough to avoid legitimate users being trapped.
- The rate-limiting schedule is a fixed period, and does not grow. This increases the cost of an attack, but means legitimate users can try again to login in a short period of time reducing the likelihood of the user needing assistance.
- The schedule for rate-limiting allows a login every 6 seconds which makes it unlikely that a user will be denied entry after entering a correct password.
- Ideally, the administrator would have a way to cancel protected mode for all accounts or a specific account, but this increases the complexity of the implementation. Removing protected mode on a password reset does not work for deployments that use LDAP to manage passwords.