Blueprint:FailedLogins - Revision history

Dominic: /* Implementation */

2025-11-11T18:44:31Z

Implementation

← Older revision		Revision as of 18:44, 11 November 2025
Line 37:		Line 37:
	An initial implementation of account locking has been implemented for upcoming Eden version 6.1, including:		An initial implementation of account locking has been implemented for upcoming Eden version 6.1, including:

	* ~~Account get~~ locked after a configurable number of failed login attempts		* Accounts are locked after a configurable number of failed login attempts
	* Accounts can be locked either for a configurable time interval, or indefinitely (ADMIN accounts cannot be locked indefinitely, however)		* Accounts can be locked either for a configurable time interval, or indefinitely (ADMIN accounts cannot be locked indefinitely, however)
	* Unlocking an account can be done using the re-enable function in the user management UI		* Unlocking an account can be done using the re-enable function in the user management UI
			* The functionality is optional and disabled by default

	=== Feedback ===		=== Feedback ===

Dominic: /* Implementation */

2025-11-11T18:43:45Z

Implementation

← Older revision		Revision as of 18:43, 11 November 2025
Line 34:		Line 34:

	=== Implementation ===		=== Implementation ===

			An initial implementation of account locking has been implemented for upcoming Eden version 6.1, including:

			* Account get locked after a configurable number of failed login attempts
			* Accounts can be locked either for a configurable time interval, or indefinitely (ADMIN accounts cannot be locked indefinitely, however)
			* Unlocking an account can be done using the re-enable function in the user management UI

	=== Feedback ===		=== Feedback ===

Dominic at 08:32, 30 October 2025

2025-10-30T08:32:48Z

← Older revision		Revision as of 08:32, 30 October 2025
Line 28:		Line 28:

	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.		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 ===		=== Solution Ideas / Proposals ===

Dominic: Created page with "* 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). H..."

2025-10-29T15:53:47Z

Created page with "* 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). H..."

New page

* [[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.

=== Solution Ideas / Proposals ===

=== Implementation ===

=== Feedback ===