Autoban failed attempts counter not using 1-hour sliding window as expected

[Granger]

Let's start with the example.

I have enabled autoban so it bans an IP after 15 failed attempts within 1 hour; a ban lasts for 1 hour. There is this client (single IP) regularly connecting to the server about once every half hour to check for files to download; they use 4 different accounts.

Recently, one of the accounts being used was deleted, but the other side didn't get around to turning off their checks for that account. So every half hour or so, there are 3 successful logins and 1 failed login.

The problem (besides the obvious: that they need to stop using the deleted account) is that every 7.5 hours, their IP gets banned for an hour, blocking the other 3 accounts.

So instead of getting banned if an IP fails 15 times in an hour, they eventually get banned if they fail at all within a consecutive set of "ban for" timespans. Or, with an alternate scenario, if the settings were to ban after 10 failed attempts and they get banned for 999 hours, an IP that had 10 failed login attempts in under ~41 days would get autobanned (for ~41 days).

(Tangent/Off-topic: No, I'm not implicitly asking that the autoban counter get reset with a successful login attempt.)

What I saw in the FileZilla Server logs

Here's a paraphrasing of a log from the other day; I'm not omitting any failed attempts for the sequence:
...
7:27 AM - 421 Temporarily banned for too many failed login attempts
8:57 AM - 530 Login or password incorrect!
9:27 AM - 530 Login or password incorrect!
9:57 AM - 530 Login or password incorrect!
10:27 AM - 530 Login or password incorrect!
10:57 AM - 530 Login or password incorrect!
11:27 AM - 530 Login or password incorrect!
11:57 AM - 530 Login or password incorrect!
12:27 AM - 530 Login or password incorrect!
12:57 AM - 530 Login or password incorrect!
13:27 AM - 530 Login or password incorrect!
13:57 AM - 530 Login or password incorrect!
14:27 AM - 530 Login or password incorrect!
14:57 AM - 530 Login or password incorrect!
15:27 AM - 530 Login or password incorrect!
15:57 AM - 421 Temporarily banned for too many failed login attempts
...

autobanmanager.cpp

​https://svn.filezilla-project.org/filezilla/FileZilla%20Server/trunk/source/autobanmanager.cpp?view=markup (r7278)

In RegisterAttempt(), when an IP is already in the list, it simply increments the count and resets the timestamp (assuming the max hasn't been reached yet). And down in PurgeOutdated() it only checks that the latest timestamp is within the configured number of hours to ban in order to keep it from being purged. Which means there's no way the code could be doing what the UI promises.

On a tangent, considering the changes to the file over the past decade, this could possibly be the same issue vaguely described in ticket #1369, but I really can't tell since there's not enough information in the description. Though considering the description in #4203, that person's walking a tight-rope. :)

[Tim Kosse]

Autoban is a deprecated feature that will be removed in a future version.

The replacement is to use long and secure passwords that simply cannot be guess.

[Granger]

OK.
It would be kind of you to alter the UI to indicate the feature is deprecated & unsupported, as well as tell people a bit more about the anti-hammering functionality (e.g. how does it basically work, why it's better than autoban, does the software use tarpitting?).

I think it would save you a lot of time in the long run (less time spent in the forums educating people about, or defending the architecture). I, for one, would like to be able to inform a client the sort of mess they're going to get in when they screw up their config.

PS: I'm extremely thankful for your decision to force-disconnect a client that attempts to supply credentials unencrypted (when the account is set to require encryption for login). I'm stuck allowing FTPES for the time being, and I've noticed a few "facepalm" events like that in the logs.