Security measures proposal - User login brute force prevention, and more

Feature
1
  1. Brute force attack prevention

It appears that Discourse does not take measures to detect and prevent multiple wrong sign ins.

Good security practices should essentially be in core.

brute force attack is common attack, a successful attack mean the attacker had enough time and he was not detected.

The following method is to weaken this sort of attacks.

The system should keep track of fail attempt per account login

  • After 5 false login attempts, the user will have to answer Captcha challenge with the following attempts

  • After 10 failed attempts, transparently deactivate logins for this account for 24 hours
    Ignoring the login silently at this point will make it even more difficult for that attacker as it will not know that the attempt was voided.

At this point even the legitimate user / the victim will not be able to login, The system will send
an email to the account owner letting him know that there was suspicious activity and regular login is suspended to protect him.
The email will contain a link to a tokenized login page that the legitimate user will be able to login from in the next 24 hours ( basically 2 way authentication )

2 . Session management - and remote logout

Allow the user to logout / destroy all open session,
This feature is to allow a user who logged on a computer (library, school, friend, apple store, and forgot to logout ( I can’t count on one hand any more the times that I saw open hotmail/gmail session in public places.

  1. Email change - should require password

It appears that changing an email does not require a password, for cases like section 2 above, it will make it very easy to hijack an account for good.

corrective measures
require the user login information before changing email or any element that has impact on the ownership of security of the account

  1. Login with email only. (configurable)

Username are public information, for more security conscious setups. Allowing logins by emails only, will add another layer of security, An attacker will have to find out 2 secrets (1st the email associated with the account and the password)

5 Likes
2

I think an easier solution is to simply slow down logins a bit on each failed login, up to a limit of say 1 minute. Then brute force takes a very long time, and existing users who happen to fail login a lot will be only mildly inconvenienced.

3

Any measures are better then no measures.

1 minute slow down, will still allow 1440 tries a day.
And can potentially prevent the legit user from login completely, The user will have to try real hard or be lucky that is own login attempt will register before that attacker attempt.

Note that technically suspending Login for attacked account, will not necessarily affect the legitimate user that is already signed in.It will only affect him if he signed out and have to sign in again. ( or if the attack persist for long period of time )

4

For the initial pass, @eviltrout is going to make sure we have some basic rate limiting on the password attempts with inserted delays.

We can continue to improve it from there, but let’s start with the basics.

1 Like
5

It looks like we already have rate limits on password reset. Current behaviour:

  • Up to 1 reset per minute
  • Up to 6 requests per hour

I think that is sufficient for now.

2 Likes
6

Is there any limits on login attempts?

1 Like
7

As for remote logout - this is already implemented on the admin side, just need a button for users to do it.

3 Likes
8

Another thing that could be thrown in is a captcha after a certain number of login attempts.

9

This is interesting. I like the concept of popping a captcha (and it adds that security feeling end users like).

10

This is not a good idea, because it’s a very easy denial of service against an account. Lockouts should never be on an account, but on an IP address.

1 Like
11

Yes. To prevent denial of service. The system will generate a “back door” a tokenized login link that will be sent by email to the account holder.
And the user only have to log in if they logout, so it is unlikely to cause major inconvenience.

IP blocking can also be used to cause denial of service for users sharing IP for example users on the same NAT network in an organization or In bigger scale a mobile network provider where many users can share same public ip. VPN provider. Etc.

At a certain level IP blocking is also an effective and common solution.

my proposed mechanism can provide a really high account security. making it extremely unlikely that even an attacker
with resources (botnet, captcha solvers for hire) to mange to successfully brute force a password.

12

:thumbsup:

Another thing, continuing a little bit from this topic: It has always irked me (not in Discourse, but elsewhere) when I forget my password, but I’m also unaware what the original password requirements were, so I don’t know what I would have chosen as my password. I then do a password reset, am reminded of the requirements, and end up choosing the same password I had originally.

Displaying the password requirements after the second or third failure would be a nice feature. It doesn’t detract from security, because password requirements are not fundamentally sensitive (i.e. they are displayed to all new registrants).

3 Likes
13

You should look at 1password

I use this for everything work related and soon everything home related. It generates passwords to so you don’t pull a junk one from your mind. And over time the goal will be that no two websites have the same bunko passwords…ever.

You can export your password file to other instances…mobile too.

14

Note: I just added an extra rate limit (will be backported to stable)

30 login attempts per hour, 6 per minute.

4 Likes
15

I love the theory behind allowing users to “log out everywhere”

But in practice, the distinction is just too hard for end users to make. In fact even GMail no longer gives you this option.

This feature request is quite big and unfocused, it is also part implemented.

Closing, but feel free to open specific feature reqs if you feel part needs to be addressed (as opposed to a kitchen sink one)