> On 7 Aug 2017, at 07:20, Jens Kubieziel <maillist@xxxxxxxxxxxx> 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-passwords/ 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 ------------------------------------------------------------------------
Attachment:
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ tor-project mailing list tor-project@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project