Brute-Force Protection

[dmeier86]

Rocket.Chat Version: 0.51.0
Running Instances: 1
DB Replicaset OpLog:
Node Version: 4.5.0

See:
#2737
We do need a brute-force-protection or at least an implementation for fail2ban.
Failed logins are written in the Logs at Admin-Interface - but fail2ban can't read those.

Any Solution anyone?

[nixwizard]

When dealing with distributed brutefroce, reCaptcha it more effective than banning IPs. It would be nice to have a possibility to turn it on for the login process.

[TwizzyDizzy]

@rocket-cat close

Closing this in favour of #2737. If you think this is not correct, please get back to me :)

Cheers
Thomas

[ruKurz]

I like the title of this issue! It states out the real intention: "prevent brute force attacks" (unfortunately the description is reduced to log failed login attempts).

To fend off Bruteforce attacks effectively there are a lot of things you can do against it, e.g.

• Strong passwords (implemented | [NEW] Implement a local password policy #9857)
• Two-Factor Authentication (implemented | but not mandatory Mandatory 2FA #9233)
• Growing delay until the next login, after failed authentication attempts (open | no issue)
• Limit number of invalid logins (open | Limit Number of Failed Login Attempts #2737 this is not just about logging, but about limiting failed login attempts)
• IP Whitelist / Blacklisting (open | instrucure or software?)
• Do not use "admin" as username (possible | by design)

Some of them are implemented at the application level and some at the infrastructure level. While logging of failed login attempts is taken over by the application, fail2ban is a system component, outside the runtime of the application. For example, failed logins could also be stored in the database. And after a configurable number of failed attempts, the affected user account is then locked.

EDIT: added growing delay until the next login

[TwizzyDizzy]

For example, failed logins could also be stored in the database. And after a configurable number of failed attempts, the affected user account is then locked.

This is not a good idea, because then I can lock you out of your account.

Tarpitting (increasing waiting time before new login can be tried) based on the source IP seems to be a good way.

This way you cannot lock my account because if you try, my logins are still not tarptitted because I (usually) am from a different IP.

Cheers
Thomas

[ruKurz]

Agreed! Before locking an account, delaying further authentication attempts is better. For example, if you make 5 failed attempts, your iPhone will lock for 1 minute, 6 attempts will lock it for 5 minutes, 7 will lock it for 15, and anything more than that will lock it for 1 hour.

But after many failed attempts the user ID should be blocked anyway. This is also recommended by the BSI (ORP.4).

For both increasing delay and account locking, login attempts must be stored in the database.