On 7 Aug 2017, at 07:20, Jens Kubieziel maillist@kubieziel.de wrote:
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.
Is it possible to lock out all the admins?
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.
Do we have a way of restoring from backups to the state before a TRAC_ADMIN compromise?
Or would that involve sacrificing all other updates after compromise as well?
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.
Use a compromised passwords list as a way of rejecting easily guessed passwords:
https://www.troyhunt.com/introducing-306-million-freely-downloadable-pwned-p...
Require the trac replacement to support 2FA.
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------