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:
- 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.
- Patch our current version This is not a standard feature of the version
of kerberos we are using, so would require kadmind patches.
- 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.
- (heimdal also has an equivalent pluggable interface)
Issues
Including...
- SL5 comes with kerberos version 1.6.whatever; SL6 comes with 1.9.something
- we would have to patch the kadmin daemon if we really wanted to keep our
current kerberos version
- patches for at least some pre-1.9 versions do exist
- but the version distributed in
Russ Allbery's
krb5-strength is against 1.4.4
- the patch is against one of the libraries used
by the kadmin daemon, so some packaging/conflict issues may well arise unless
we replace the kerberos installation on the KDCs wholesale
- but that would likely bring its own dependency problems
- but there's no point in that, since it's obsolete and when
we go to SL6 we'll have to change kerberos versions anyway
- and the version in SL6 (1.9.x)
appears to have the pwqual plugin interface in it already
- assuming we can find (or write) a suitable plugin
- 1.9 has some other goodies in it that we might well want to use
- there are likely to be some configuration differences between
kerberos versions 1.6.x and 1.9.x,
though we would have to look at that in due course anyway
- DevProj #223
- in particular we have to be aware of single-DES for AFS
- should we be radical and look at heimdal while we're at it??
- a rather bigger job with wide implications
- the SL6 stock version 1.9.whateverItIs
does appear to have most of what we need
- once we're not limited to kadmind's built-in rules, do we want to tweak
the password policy at all?
- we'll definitely need to have some way to configure the plugin(s)
Recommendations
- 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.
- 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.
- 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.
- Once we have the KDCs upgraded, consider:
- whether the cracklib rules then in place are sufficiently strong
- whether we should augment the dictionary set
- whether we should add any other plugins
- whether the kadmin daemon's password history is long enough
- When we upgrade the iFriend KDCs, apply the same mechanisms there, though
perhaps with different policies defined.
Links