[tor-project] Make it harder to brute-force Trac user passwords
teor2345 at gmail.com
Mon Aug 7 06:39:29 UTC 2017
> On 7 Aug 2017, at 07:20, Jens Kubieziel <maillist at kubieziel.de> wrote:
> 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
Or would that involve sacrificing all other updates after compromise as
> 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
> 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
Require the trac replacement to support 2FA.
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
xmpp: teor at torproject dot org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: Message signed with OpenPGP
More information about the tor-project