Server: Clear bruteforce protection from user upon successful login

Created on 19 Jan 2017  路  6Comments  路  Source: nextcloud/server

Steps to reproduce

  1. Get throttled via via request (keep logging in with wrong pw)
  2. Login with correct pw

Expected behaviour

  1. Requests should not be throttled anymore

Actual behaviour

  1. Requests to endpoints are still throttled

Extra points for the following:
When a user is already in the blacklist, and auth.bruteforce.protection.enabled is set to false, the requests are still throttled.

enhancement authentication good first issue

Most helpful comment

Solution provided at https://help.nextcloud.com/t/solved-bruteforce-detection-blocking-my-ip-but-theres-no-oc-bruteforce-attempts-database/7652 (extend solution by clicking [v]). I purged all with DELETE FROM oc_bruteforce_attempts;

All 6 comments

The config surly sounds like an issue.

However keeping the throttling sounds okay to me. It will expire after some hours if no further login attempts come in. But since we are using this more and more it should not really immediately forget all those...

Same issue here, a big problem is nated trafic, all my clients are affected because the cloud domain has the public ISP-modem IP.
(so the modem forwards 443 trafic from the public ip to the internal cloudserver )

All requests from my public IP are slowed down, so all external clients are not able to use the service.
Anny ideas to fix that ?
edit:
The app is not able to connect

Solution provided at https://help.nextcloud.com/t/solved-bruteforce-detection-blocking-my-ip-but-theres-no-oc-bruteforce-attempts-database/7652 (extend solution by clicking [v]). I purged all with DELETE FROM oc_bruteforce_attempts;

cc @LukasReschke The middleware doesn't log the user in the brute force table. Should we add a hack there or for now ignore this one and only focus on the session this which properly logs the user ID?

The middleware doesn't log the user in the brute force table. Should we add a hack there or for now ignore this one and only focus on the session this which properly logs the user ID?

This was fixed recently and can be implemented now.

Fix is in #7263

Was this page helpful?
0 / 5 - 0 ratings