Feature #3096
open
Lock accounts after X failed attempts
Added by Ben Blier about 15 years ago. Updated 8 months ago.
50%
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
Updated by
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...
Updated by Adam Kubica about 15 years ago
+1 (failed attempts number should be configurable)
Automatic unlocking after some period might be security problem.
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.
Updated by Alexander J. Murmann about 15 years ago
- % Done changed from 0 to 50
I can see the following alternatives:
- After a timeout, as suggested earlier
- Notification email contains a link that will unlock the account again
- You have to deal with an admin outside the system and he has to manually unlock it
- 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?
Updated by Alexander J. Murmann about 15 years ago
- File login_attempts.diff login_attempts.diff added
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.
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.
Updated by Alexander J. Murmann about 15 years ago
- File login_attempts.diff login_attempts.diff added
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!
Updated by
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?
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 ?
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.
Updated by
Updated by Mischa The Evil over 9 years ago
Updated by Mischa The Evil over 9 years ago
- Related to Feature #3155: Password policy and secure logon procedure added
Updated by
Updated by Mizuki ISHIKAWA 8 months ago
- File login_attempts_v2.patch login_attempts_v2.patch added
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.
- 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.
Updated by Pavel Rosický 8 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
Updated by Mizuki ISHIKAWA 8 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,
Updated by Pavel Rosický 8 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 :)