View source for Blueprint:FailedLogins

* [[Blueprint:Index|All Blueprints]]

== Handling of Failed Login Attempts ==

=== Background ===

As of Eden version 5.x, failed login attempts are logged - but have no further consequences. Users can make an unlimited number of attempts to login to their account.

=== Problems ===

Sensitive deployments may want to prevent brute-force attempts to login, and therefore need a way to configure consequences for multiple consecutive login failures (e.g. locking accounts). However, automatic locking of accounts, and hence locking out of users, can be disruptive for critical business processes and itself provide an attack route.

Large numbers of consecutive login failures can also indicate automated break-in attempts, and should be detectable (traceable) by automatic means - either at the application level, or better - at the infrastructure level.

=== Analysis / Requirements ===

The default behavior should remain to just log failed login attempts.

Consecutive login failures should be counted for the account (either counting up, or counting down from a setting-defined limit). The failure counter would be reset once the login was successful.

Deployments should be able to configure all of the following with settings:
* once a certain number (=setting) of consecutive login failures for an account has been reached, the account is blocked for any further login attempt. The default for this setting should be <code>None</code>, disabling automated locking.
* if the server is permitted to send verification emails (=setting), it would send a notification email to the user, informing them about the lock-down of their account and the reason for it
* this notification can either include advice to contact their administrator to get their accounts unlocked, or contain a link+code for self-unlocking. The text of the notification email should be customizable.
* it should also be possible to set a time limit for locked accounts (=setting), after which the account is unlocked automatically. The default for this setting would be <code>None</code>, disabling automatic unlocking.

User administrators (ADMIN or ORG_ADMIN) can unlock the account manually at any time.

It is also important that login attempts to locked accounts return a specific HTTP error status (distinct from 403) as a detectable indicator for infrastructure-level security (e.g. a WAF), so that suitable countermeasures can be deployed automatically.

We must be mindful that, if manually resetting the lock by an admin would be the only way to unlock an account, then we must never lock admin-accounts or at least not indefinitely. Therefore, one of the two alternatives must apply: either the possibility of unlocking per email verification, or a lock-timeout.

=== Solution Ideas / Proposals ===

=== Implementation ===

=== Feedback ===