Last modified: 2014-09-28 23:59:00 UTC
There is limited/insufficient security with the passwords. OTRS is fairly lenient when it comes to requirements. Znuny has created an add-on for this (see URL above). We use a couple of other Znuny patches so is it fair to assume that we have the "Znuny4OTRS-Repo" installed? It seems to be required for the patch to work. I've added bug 60271 as a blocker to this. If the Znuny repo is set and this all checks out, it would be nice to include this with the upcoming upgrade.
One question, do you have a LDAP directory at Wikimedia? So you could use the authentication from this. Otherwise I also recommend to use Znuny4OTRS Password Policy.
(In reply to comment #1) > One question, do you have a LDAP directory at Wikimedia? So you could use the > authentication from this. Otherwise I also recommend to use Znuny4OTRS > Password > Policy. Yes, Labs ("Wikitech")/Gerrit is using LDAP as a backend. Although moving everyone over might be a pain.
My vote is to keep OTRS as a standalone and use the Znuny4OTRS Password Policy package.
There are some configuration options to decide on. Here are the basics: Enforce a password renewal after X (configurable) days. Password-History to use the password X (configurable) times not to use again. Disable account after x invalid login attempts. Minimum size of the password. At least 2 small and 2 big letters in a password. At least 2 letters in a password. At least one number in a password. My suggestions: PasswordMaxValidTimeInDays 180 PasswordMaxLoginFailed 5 PasswordMinSize 10 PasswordHistory 3 (can't reuse the last 3 passwords)
Sounds good to me. Is 5 a bit high for 'PasswordMaxLoginFailed'? I'd feel better around...3. 4 if you insist. But that's just me.
None of these features seem desirable, except the minimum password length (it's somewhat astounding that that wouldn't be built into OTRS, though). 6 would probably be a sane value.
To clarify, simply disabling accounts after x invalid logins presents a clear DoS vector. Anything like this needs to be done on a per-hostname basis. See https://bugzilla.wikimedia.org/show_bug.cgi?id=9816#c13 and related discussions.
While I like the idea of PasswordMaxLoginFailed in principle (because you can currently make endless attempts to crack an account), I see a problem with it here. (To my dislike) the list of login names is published. If PasswordMaxLoginFailed is enabled, someone could easily disable all accounts.
Regarding PasswordMaxLoginFailed I squinted at code and config and the feature does not appear to pay any attention to client host. I'm not sure whether that's good or bad--if it were host-specific it would be pretty easy to bypass. But whereas lockouts are usually time-based (i.e. 3 failed attempts gets you locked out for 10 minutes) I don't see anything in the code having to do with timers or auto unlock. I could be missing something. If this is in fact the case, and lockout requires manual intervention by an other admin, I would suggest we set it to ~10. I understand the DOS concern but IMO it's an acceptable tradeoff for not leaving ourselves wide open to brute force attacks. We can easily disable the lockout feature if it becomes a problem. Password length--6 is way too short, especially without other features to slow down brute force attacks.
I think it is not a good idea to install the PasswordMaxLoginFailed check if it really disables the account. The accountnames are all known. There are only 9 admin accounts (all login names known) that need to be attacked and the OTRS is locked down if an attacker does 90 login attempts with these accounts. This risk is much higher than the risk of a brute force attack on passwords that would require massive amount of login attempts and can not be successful if the passwordstrength rules are enabled. Best regards Neozoon
I am not convinced that security is improved by setting PasswordMaxValidTimeInDays to low values as suggested, i.e. 180 days. Frequently enforced password changes force people to write their passwords down, to use passwords that can be more easily memorized, and/or to use some schemes that help them to remember changed passwords (e.g. changing just the last character of a password). All this weakens security. Here is a good essay by Gene Spafford regarding changing passwords: http://www.cerias.purdue.edu/site/blog/post/password-change-myths/
I would like to second Neozoon in his comment above. The logins of the OTRS admins are well known. This discussion is in the public. To set PasswordMaxLoginFailed is an open invitation for the next vandal to get all OTRS admins locked out. Do not think that such incidents are unlikely. As Wikimedia and the support team are well known entities, it is just a question of time when eventually such an attack will be launched. This is not an "acceptable tradeoff," we would look like fools in the moment when it happens. And it does not matter whether PasswordMaxLoginFailed is set to 3, 10, 100, or whatever. Any limit can be reached if a vandal has the intention to launch this attack. I would recommend to protocol any login failures, to evaluate these logs every n minutes, and to block the IP addresses that generate more than m login failures within n minutes. Similar strategies tend to work out against brute force attacks on ssh logins.
Closing - this can be revisited later if necessary, pending further discussion elsewhere.
