Project

General

Profile

Actions

Feature #3096

open

Lock accounts after X failed attempts

Added by Ben Blier about 15 years ago. Updated 10 months ago.

Status:
New
Priority:
High
Assignee:
-
Category:
Accounts / authentication
Target version:
-
Start date:
2009-04-01
Due date:
% Done:

50%

Estimated time:
Resolution:

Description

I believe Redmine should have the functionality available to put accounts in to a locked state after so many failed login attempts. The number of failed attempts should be configurable via the Administration panel. Notification to an administrator e-mail address that the account was locked is desired as well.

I am surprised this feature has not made it in to Redmine yet. Could this be something that makes it in to a 0.9 release? I plan on exposing my Redmine instance to more than just internal folk within the next 6mo-1yr. I do not want to give any external entity the ability to brute force my password.


Files

login_attempts.diff (12.9 KB) login_attempts.diff probably buggy patch Alexander J. Murmann, 2009-04-13 05:25
login_attempts.diff (13.8 KB) login_attempts.diff Alexander J. Murmann, 2009-04-27 04:26
login_attempts_v2.patch (16.1 KB) login_attempts_v2.patch Mizuki ISHIKAWA, 2023-08-28 04:56

Related issues

Related to Redmine - Feature #3155: Password policy and secure logon procedureNew2009-04-10

Actions
Actions #1

Updated by Jens Goldhammer about 15 years ago

+1

Actions #2

Updated by Maxim Krušina about 15 years ago

+ function to email admin/user about locking. Also account can be optionally unlocked after some (probably configurable) period, like 1 hour...

Actions #3

Updated by Adam Kubica about 15 years ago

+1 (failed attempts number should be configurable)

Automatic unlocking after some period might be security problem.

Actions #4

Updated by Alexander J. Murmann about 15 years ago

+1
I also think this might be very useful.
I just started working on a patch for this.

Actions #5

Updated by Alexander J. Murmann about 15 years ago

  • % Done changed from 0 to 50
I am almost done with the patch but was wondering how accounts should be unlocked.
I can see the following alternatives:
  1. After a timeout, as suggested earlier
  2. Notification email contains a link that will unlock the account again
  3. You have to deal with an admin outside the system and he has to manually unlock it
  4. Go through "forgot password" and reset the password and when the password is reset the account will be unlocked.

I personally think that 2. would be best.

Any thoughts about this or other suggestions?

Actions #6

Updated by Ben Blier about 15 years ago

#4 isn't a viable option since my LDAP is read-only and I don't even know if "Forgot password" works with LDAP (probably not).

It would be best if the admin is given the option to configure #1, #2, or #3, but I'll take either #2 or #3.

Actions #7

Updated by Alexander J. Murmann about 15 years ago

I implemented solution 2. Although if there is need it should be very easy to add an option to use 3. in addition.

Attached is a patch that should allow the admin to define a number of allowed login attempts and the address of an admin.
If a user fails to login the flash-message will show how many logins are left. If none are left the flash tells so and the account gets locked. A mail informing the provided admin address will be send. The suer will also receive a mail telling him what happened and providing a link to reactivate the account.

However since I am a bad boy I didn't write unit tests yet. So there still might be something wrong. I will provide another patch which will include tests later this week.

Actions #8

Updated by Eric Davis about 15 years ago

Thanks Alexander. Once you add some unit tests I'll be able to take a closer look at applying this patch. From a quick glance User#authentication_failed could be cleaned up a bit. I see two calls to self.save! and no handling of their failure cases.

Actions #9

Updated by Alexander J. Murmann about 15 years ago

I added a unit test and changed the two 'save!'s to 'save' since I could not come up with a useful way to catch a failed save.

Please let me know if and how I can improve the patch further!

Actions #10

Updated by Michael Litton about 15 years ago

Great, I really need this.

Actions #11

Updated by Ben Blier almost 15 years ago

I'm curious if anybody has been running this patch in their environment... What are your thoughts? Anything that could be improved?

Actions #12

Updated by S Reid about 13 years ago

Is this still the only method to lock accounts after failed retries ? Does it work with the current version of redmine ?

Actions #13

Updated by Nuno Duarte about 13 years ago

I believe this feature would improve a lot redmine security. Giving more confidence to me and my clients.

Actions #14

Updated by @ go2null over 9 years ago

duplicate of #3155

Actions #15

Updated by Mischa The Evil over 9 years ago

@ go2null wrote:

duplicate of #3155

Not completely. #3155 is older than this issue and it is much more generic, while this issue is specific to one requested change. So I'll add a relation, but won't close this one as duplicate.

Actions #16

Updated by Mischa The Evil over 9 years ago

  • Related to Feature #3155: Password policy and secure logon procedure added
Actions #17

Updated by François Bélingard over 9 years ago

+1

Actions #18

Updated by Mizuki ISHIKAWA 10 months ago

A patch for this feature is attached.

Features/Changes provided in this patch:
  • Administrator set max_login_attempts (int) in the admin settings panel (default is nil).
  • If a user exceeds this number of failed login attempts, their account will be locked.
  • The timing for displaying l(:notice_account_locked) has been changed to prevent attackers from identifying the correct password.
  • An email will be sent to the user when their account is locked.
  • A security notification email will be sent to the admin when a user's account is locked.
  • The lock can be lifted in one of the following ways:
    • An email sent to the locked user will contain a URL to unlock their account.
    • Admins can unlock the user from the user list.
Features not included in this patch:
  • Auto-unlock feature after a certain period has elapsed (After this patch has been merged, it is better to address this in a other issue if necessary.).

I am not a security expert, so I would appreciate it if you could confirm that there are no issues with these specifications.

Actions #19

Updated by Pavel Rosický 10 months ago

wow 14 years :) Unfortunately from my experience, there are two issues with this approach:
1/ someone could easily lock the whole system if he knows the login (which is usually public or simple to guess). You'll notice the attack, but it's a nightmare for the administrator.
2/ without required twofa for all users, it's not sufficient protection against spraying attacks https://www.hypr.com/security-encyclopedia/password-spraying-attack

Actions #20

Updated by Mizuki ISHIKAWA 10 months ago

Pavel Rosický wrote in #note-19:

wow 14 years :) Unfortunately from my experience, there are two issues with this approach:
1/ someone could easily lock the whole system if he knows the login (which is usually public or simple to guess). You'll notice the attack, but it's a nightmare for the administrator.
2/ without required twofa for all users, it's not sufficient protection against spraying attacks https://www.hypr.com/security-encyclopedia/password-spraying-attack

Thank you for your feedback.
1 /
You're absolutely right that this approach could be exploited to lock out users, causing a headache for administrators.
In anticipation of this, the feature is disabled by default, allowing administrators to opt-in only if they find it suitable for their specific use-case.
If an account is locked, users can unlock themselves via a URL sent to their registered email. Additionally, the IP address of the user attempting the lockout is logged and sent to administrators, who could then potentially block the IP at the server level using tools like Apache.

2 /
The patch I submitted does not include a "reset login attempts over time" feature. This means that even if an attacker uses a password spraying attack technique with long intervals between attempts, they will still be limited by the maximum number of allowed attempts. Even if a "reset login attempts over time" feature were to be implemented, it would not make the situation worse for instances of Redmine where two-factor authentication is not enabled, as attackers could already make unlimited attempts under the current system.

Many Thanks,

Actions #21

Updated by Pavel Rosický 10 months ago

Redmine should have some kind of default protection against these types of attacks and your implementation is fine, at least it protects against cracking passwords in the background without any notification...

but in my opinion, a rate limiter + captcha would be a better option. Administrators could still be informed about the attack, but in reality, it takes some time for administrators to take action. A malicious actor could make the system unusable without much effort (locking users over and over) until the administrator bans the IP and then he can start again from a different IP. The feature protects against stealing passwords, but on the other hand, it opens a new opportunity, to shut the application down / block regular users from using it.

I'm also not a security expert, so I'm open to other opinions :)

Actions

Also available in: Atom PDF