168: Password strength checks -- evaluation

This project (index, descriptor) is to evaluate our existing password strength-checking mechanisms, to make recommendations, and possibly to implement some or all of those recommendations. Some of these mechanisms have recently been strengthened, thereby subsuming part of this project, but there are still some enhancements which could be added and rough edges and inconsistencies which might be ironed out.

Existing checks

The current password policy is as described here.

Password-setting on a DICE managed desktop would normally be done using the passwd command, which uses the PAM stack to call a series of modules. As configured, we first call out to cracklib to perform its checks. If those succeed, the password-change is then sent over the wire to the kadmin machine, which performs its own policy checks. If those also succeed (the character-class check should, as it's a subset of what cracklib does, but there's also the possibility of falling foul of any password-history checks) then the password is changed in the KDC.

However, this can easily be short-circuited by use of the kpasswd command, which ignores the PAM configuration and calls directly to the kadmin machine. Users using this mechanism could set weaker passwords than those going through passwd and the PAM stack. In particular, although kadmind's basic character-class and history checks would still be performed, cracklib's additional checks for permutations and rotations, dictionary checks, 31337-speak and so on wouldn't. We could, of course, remove the kpasswd utility from managed DICE machines, which would force anyone who can't drive a compiler to use passwd. However ...

There is also the issue of how self-managed machines are configured. It seems likely that these would have a local password arrangement, which the usual passwd command would be set up to affect, and any kerberos changes would naturally be made using kpasswd. Likewise Kerberos for Windows (KfW) machines might go directly to the kadmin machine. These cases are, therefore, subject only to the kadmin daemon's rules. Relying on client-end checks is not usually good security practice, of course.

(Aside: we have, of course, no way to enforce password policy on any principals obtained through cross-realm trust, other than for iFriend. We should bear this in mind when setting authorisation rules.)

Options

The issue at hand, then, is whether the kadmin daemon's policy checks on their own are considered to be sufficient, or whether we would prefer that the additional power of cracklib or the like could usefully be made available to the kadmin daemon. These are the options:

  1. Do nothing. We might conclude that our existing mechanisms are sufficient, and that any additional gain to be had from enhancing these would not justify the work required (see "issues" below). Relying on client-end checks is not, in general, good security practice, but in the secure/cheap/easy-to-use tradeoff we might in this case consider it useful and good enough, particularly if we were to remove kpasswd from the managed DICE desktops.
  2. Patch our current version This is not a standard feature of the version of kerberos we are using, so would require kadmind patches.
  3. Migrate to kerberos 1.9.x (upgrade the KDCs to SL6). Pluggable password quality checks are on the MIT-kerberos version 1.9 roadmap, and appear to have appeared in at least 1.9.2. The System Administrator's Guide which comes with the SL6 krb5-server RPM does mention the pwqual plugin, which is a hopeful sign.
  4. (heimdal also has an equivalent pluggable interface)

Issues

Including...

Recommendations

  1. There is no point in patching the existing code, since we will soon be moving to a version with the necessary pluggable interface already built in.
  2. Wind up this project. It has served its purpose. Alternatively, stall it until DevProj #223 has completed, and then do the cracklib plugin in this project's "implementation" phase.
  3. Add at least the pwqual configuration hooks to the "KDC upgrade to 1.9" project (#223). Implement a cracklib-based plugin using those hooks. Alternatively, reawaken this project (#168) to implement the plugin.
  4. Once we have the KDCs upgraded, consider:
  5. When we upgrade the iFriend KDCs, apply the same mechanisms there, though perhaps with different policies defined.

Links