Rocket.chat: Deactivate inactive users after a time period

[ruKurz]

According to an organization's security requirements, user accounts must be automatically disabled after a specified period of inactivity. The period of inactivity should be configurable in Rocket. chat.

[ruKurz]

@TwizzyDizzy Do you agree, that user deactivation after a period of inactivity increases the security?

[JSzaszvari]

@ruKurz it's just best practice to disable the accounts. Depending on the environment the security impact could be different but should be done regardless

[JSzaszvari]

@rocket-cat label add enhancement

[TwizzyDizzy]

I think it should be the decision of the admin whether (and if so, when) inactive accounts shall be disabled. Personally I see some security benefit in it, yes, as you can't brute-force an inactive account.

EDIT: On second thought, though, it only limits the time an attacker has for brute-forcing. While on the other hand, an attacker has endless time for brute-forcing an account that is in use.

Yet I think this is a rather huge task for non-local accounts (LDAP/AD sync, oauth and so forth). You would have to consider the implications there, too.

Also you would have to have some re-enabling process for the user.

Overall, I would think that we should rather implement some anti-brute-forcing technique (slowing down site-loading, asking for captchas after X tries (bound to an IP address)... sth. like that. For an attacker, time is of the essence. You can only limit the attacker's time he has to spend for a try. Increase this, and the time the attacker has to invest per try will soon be too high to cover the whole character space for a decently long password.

Cheers
Thomas

[fcoppolani]

Hi,

there is #6174 also. I believe it should be good practice to be abble to disable users from a field in LDAP (coming from OTAUTH or SAML too). This feature could help (if a user is deactivated from an AD he won't login, so it is a way of automatically disable these users, after a period of time).

[smidt]

+1

[horvan]

This should be done soon so + 1

[speedy01]

+1 on this for me too. Having to audit user accounts in RC to deal with compliance and audits is killing me. Most enterprise try to use a single source or truth (ldap/ad/etc) to help reduce this issue. Ideally, Id like to see users removed from RC when they are deleted from ldap/ad, but the next best thing would be automatic deactivation.

[mrsimpson]

I'll just start implementing an API to deactivate users which have been inactive for a longer time.
This is kind-of an intermediate step to automatic deactivation which requires some scheduler. This could be added as a second step

[axkibe]

To best fullfill GDPR regulations of the EU unused accounts, I'd like not only to have them deactivated, but unused accounts should best be automatically deleted, including personal data (which is the name and email). (or at least the data in the database should be replaced by empty values, (email, name, password))
I guess for now I have to do this manual every so often?