Hi,
recently I had a discussion with GeKo about brute-forcing trac accounts. Someone reported that trac allows to test username/password combinations without having an upper limit. This resulted in https://trac.torproject.org/projects/tor/ticket/23120 and I set the the maximum amount to 17 (chosen arbitrarily). When an account is locked an admin has to unlock it. However I received some mails who raised the point that people can now lock out legitimate users quite easily. Thatswhy I want to discusss this here.
What happens when people sucessfully guess a password? In general people can create an account or use the cypherpunks account to gain more permissions. So it doesn't make sense to guess those passwords. However it gets more interesting when someone guesses the password of a member of the TRAC_ADMIN group. Then the attacker can read our configuration and create some havoc. However with the current setup it is hardly possible to change trac.ini. Even TRAC_ADMIN has not the permissions to do so.
So we lived with this risk in the last years and simply relied on the fact that people choose a secure (aka hard-to-guess) password. So we just could return to this state.
If we choose to do something against password-guessing attacks, we could choose the current solution. This means after n attempts (currently n=17) the account gets locked and only a admin can unlock it. This has the risk that attackers can lock out legitimate users.
The trac cookbook list some other possibilities (URL:https://trac-hacks.org/wiki/CookBook/AccountManagerPluginConfiguration) to configure the account locking. In general it can be configured to release the lock after some amount of time. However each visit to trac happens at Unix epoch by configuration, so the plugin would never release the lock. If we want to configure automatic unlocking, we would have to change our webserver settings (as far as I see it).
How should we set up trac regarding brute-forcing? Are there other possibilities I missed? I'd love to hear your feedback on this.