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.
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 ------------------------------------------------------------------------
* teor schrieb am 2017-08-07 um 08:39 Uhr:
On 7 Aug 2017, at 07:20, Jens Kubieziel maillist@kubieziel.de wrote: 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?
One can lock every account on trac. If an account is locked, a person with SSH access has to login to the trac machine and to reset the account. So every locked account can be reset.
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?
The trac machine is backupped and we could probably restore the data (assuming that the compromise didn't happen like ten years ago, the backup is OK etc.).
On 7 Aug 2017, at 16:39, teor teor2345@gmail.com wrote:
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.
Enforce a minimum password length. (Any other requirements are counter-productive, as machines aren't good at guessing entropy.)
Use an exponentially-increasing timeout for the next login every time a login fails for a user. (Some sites do it for failed logins per IP address, too, but that's silly, because open proxies.) This is equivalent to an automatically-resetting lockout, but requires the attacker to spend as much time as the lockout time setting it up.
Use some other kind of credential rather than a password. (I'd find this inconvenient, because my other credentials are hard to attach to some of the machines I use trac on.)
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 ------------------------------------------------------------------------
On Tue, Aug 08, 2017 at 01:41:06PM +1000, teor wrote:
Use an exponentially-increasing timeout for the next login every time a login fails for a user. (Some sites do it for failed logins per IP address, too, but that's silly, because open proxies.) This is equivalent to an automatically-resetting lockout, but requires the attacker to spend as much time as the lockout time setting it up.
This was certainly the first one that came to my mind.
Though actually, I don't think there's any particular reason it needs to be exponentially increasing. "0 seconds of delay for the first 4 attempts, then 60 seconds of delay for subsequent attempts" might do the trick nicely.
--Roger
On Tue, 8 Aug 2017 13:41:06 +1000 teor teor2345@gmail.com wrote:
Use an exponentially-increasing timeout for the next login every time a login fails for a user. (Some sites do it for failed logins per IP address, too, but that's silly, because open proxies.) This is equivalent to an automatically-resetting lockout, but requires the attacker to spend as much time as the lockout time setting it up.
That seems hard to do given:
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).
Without looking at the trac code. Maybe it's not.
Regards,
tor-project@lists.torproject.org
-
Jens Kubieziel -
Roger Dingledine -
teor -
Yawning Angel