[tor-project] Make it harder to brute-force Trac user passwords

[teor]

> On 7 Aug 2017, at 07:20, Jens Kubieziel <maillist at 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-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
------------------------------------------------------------------------



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.torproject.org/pipermail/tor-project/attachments/20170807/6990e1d3/attachment.sig>