[patch] Lock user after configurable number of failed login attempts

[Aliaksandr Salenka <sem7777@…>]

Is it possible to add locking users after 3 failed login attemps? It should be userfull.

[Steffen Hoffmann]

#7711 was marked as a duplicate of this one.

Limiting number of password retries is an important feature at least in cooperate applications. I suggest this should be more urgent to implement.

[Steffen Hoffmann]

Certainly this should be done.

And I guess it must be done independently of the AuthStore used, since there is no way to mark "max_login_attempts reached" and set an administrative lock within most, if not all of them.

Patch welcome.

[Steffen Hoffmann]

preview on suggested enhancement, yet somewhat incomplete

[Steffen Hoffmann]

Attached patch shows roughly what I'll come up with in absence of better code.

implemented:

• optionally limit login attempts to login_attempt_max_count (new option, default: 0 - means no limit for hassle-free upgrade)
• logging of failed login attempts to session_attribute db table
  • add entries for previously authenticated users only (polluting table with lots of random user names could even cause dangerous db growth)
  • remote IP address and corresponding attempt time included
  • keeps latest (login_attempt_max_count + 1) entries
• show active user account lock in authentication failure error message
• optional lock timeout after user_lock_timeout seconds (new option, default: 0 - means unlimited locking time)
  • hint on configured timeout displayed in authentication failure error message as well

planned:

• remove current «graceful» lock behaviour: lock is purely cosmetic now as AccountManagerPlugin continues password checking and releases lock on next successful attempt
• visualize locked user accounts at account admin page ('users')
• provide easy lock audit functionality at user admin page, i.e. by listing recorded attempts in a pop-up window

Comments, improvements and other suggestions are appreciated to help with the final cut.

[Steffen Hoffmann]

improved version

[Steffen Hoffmann]

changes to previous version:

• lock behavior fixed
• user_lock_timeout renamed to user_lock_time
• exponential lock time extension added, calculation is t_lock = user_lock_time * user_lock_time_progression exponent
• user_lock_max_time provides upper limit on lock time growth (defaults to 1 day)

ToDo

• features for admin page as mentioned before
• some more value checking to prevent useless and potentially dangerous custom configurations
• write documentation to wiki including commented example configurations to demonstrate effects of different combinations of new options

[Steffen Hoffmann]

update on development status:

core functionality is no longer extending AccountManager module directly but bundled in a new AccountGuard class instead

• user account audit information will be presented at another admin page 'details', that can't be clicked directly but requires a proper argument ('​http://../details?user=<username>')
• currently locked accounts visible at admin page 'users', click-able icons leading to details page for corresponding user
• details page holds account status information and last failed login attempts log
• login page clearly reports account lock release time on login rejection

[Steffen Hoffmann]

(In [9546]) AccountManagerPlugin: Introduce login attempt tracking and administative user account locking, refs #7437.

Number of previously logged failed login attempts as well as lock condition and lock behaviour are evaluated and displayed to the user. Optional exponential lock time prolongation can be used to further reduce effectivity of attempted brute-force attacks on user passwords.

[Steffen Hoffmann]

(In [9548]) AccountManagerPlugin: Add admin functions for user account locking, closes #7437.

We show information related to new account locking, but be prepared for an even richer account details view here, i.e. including information regarding password reset and account/email verification status.

[Steffen Hoffmann]

(In [9555]) AccountManagerPlugin: Fix user_locked() method, refs #7437.

Just noticed, that it returned false positive «locked permanently», if account locking had been turned off by (default) configuration.