Brute force protection for serendipity login

[stephanbrunker]

I don't have that much experience, but for a project of mine I have realized an protection against brute force attacks on the login. Because we all know that too much users use passwords which doesn't have that much complexity, one solution is to limit the number of login attempts in a given time frame. For example, after 20 attempts block the user for one hour. This is the same as in Girocard protection which has only 2^13 possibilities, but is blocked after three wrong attempts.

To realize that, you'll need two additional fields in the user data: last login and login attempts, everything else is not that complicated.

But I really don't know if that is necessary or not.

[fe-hicking]

I‘d be all for it! Sounds good to have. However, how do I protect myself that someone who tries to login with my username and uses a bot that tries ever 5 minutes, so a constant lock would happen?

[onli]

You are worried about someone locking a user out? The block should be combined with the IP, not just the username

[fe-hicking]

Yeah exactly. But if its locked to an IP it can be brute forced again with botnets easily, which have many IPs to outsource to.

[stephanbrunker]

I never thought of the lock-out scenario. But in that case if someone is laying siege to your site, you have really a problem. It depends somewhat on the users involved: If the password is strong enough which should be the case for administrators, it shouldn't be necessary. But for the page I built I didn't hash but encrypted the passwords in the database that I can decrypt them and check (I know, that is dubious too, but the users are my employees and the data is critical). The reality is unfortunately that common users mostly use passwords which aren't very secure. I just looked into Joomla and there is only a timeout for the "forgot password" function and the login attempts are logged, but not restricted. On the other hand, the Internet connection by Deutsche Telekom blocks you after only three or five attempts (easily if you put the wrong numbers in your router and it tries again) and locks you out until midnight. So, really hard to say if this feature would be an improvement in site security or a risk for DDOS attacks.

[onli]

Having the integrated intelligence to throttle/ban an attacker would be nice and a net win in my opinion. The ddos scenario is way harder to implement (from the attacker perspective) than a simple bot trying to guess the password. So if we can make the simple attack scenario harder we gain a bit of security in the more realistic scenario.

Note: fail2ban (+password authentication on apache level) would already allow that now.

[th-h]

+1, as long as it's configurable ... or tied to the attacker's IP address.

User names often are easily guessable, but passwords should be strong; at least that's what I do. So the danger of getting locked out is much greater - for me - than bruteforcing a password. Making the throttling just apply to the attacker's address would mean we have to save IP adressess (and add that to the privacy statement, at least for other user accounts), but that would prevent getting logged out.

But if its locked to an IP it can be brute forced again with botnets easily, which have many IPs to outsource to.

That's harder to do than just bruteforce it from one host (even considering ipv6).

We could think about adding two-factor-authentification, too.

[fe-hicking]

We can hash the IP adress so that the actual IP address wouldnt be stored...