View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0026794 | mantisbt | security | public | 2020-03-17 05:08 | 2020-12-30 07:37 |
Reporter | randomdhiraj | Assigned To | dregad | ||
Priority | high | Severity | major | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Target Version | 2.24.4 | Fixed in Version | 2.24.4 | ||
Summary | 0026794: User Account - Takeover | ||||
Description | It was observed that the POST request for | ||||
Steps To Reproduce |
Please find below attached PoC for your reference in which I've sent 100+ dummy request which contains wrong password for username | ||||
Additional Information | There should be a lockout mechanism in place or throttling against such bruteforce attack. | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
There is configuration option |
|
Atrol, Thanks this does the job. Aside I believe this should be enable by default as a best practice. |
|
As always there are pros and cons. |
|
I would tend to agree with @randomdhiraj that we should change this default from OFF to some fixed value - threshold can be discussed, but 5 seems reasonable. |
|
Thanks Dregad & Atrol. |
|
@dregad I don't think we should lock the user account forever when an attacker attempts to attack them. I wonder if we are better off using the tokens_api to have a temporary block. We introduce a token type ACCOUNT_LOCKOUT_IPS which has a lifetime of 5 minutes and its value is an array of IP addresses.
I'm referring to the API in tokens_api.php. Also changeo of this behavior is better done in a proper release and not a patch release - this may be the intention but it is hard to tell without having a specific cherry-pick commits or a PR for 2.24.x vs. master-2.25 for example. |
|
Thanks for the feedback Victor.
Apologies, I forgot to set the target version, have done it now (2.24.4). The current, lockout is how the system has been working until now (assuming the admin has set $g_max_failed_login_count > 0), and this has never caused any issues. Considering that the user can unlock the account themselves by following the usual password change mechanism, I think the increased security we get by changing this config's default is a minor change that definitely fits in the scope of a hotfix release. Admins relying on external authentication (e.g. LDAP) can -- and should -- set this to zero; maybe I can update documentation to reflect this (and mention that under $g_login_method too). Temporary lockout would be a nice feature, but that's not something I would implement as part of a security release. I have opened #27741 to track this for later implementation. |
|
MantisBT: master 30b37742 2020-10-10 04:04 Details Diff |
Default max_failed_login_count to 5 Update documentation accordingly. This prevents brute force attacks to gain access to users' accounts. Fixes 0026794 |
Affected Issues 0026794 |
|
mod - config_defaults_inc.php | Diff File | ||
mod - docbook/Admin_Guide/en-US/config/signup.xml | Diff File |