Toby Blake <t...@inf.ed.ac.uk> writes:
> Hi Russ, when you say "the CrackLib code in there is suspect", do you
> mean in the current krb5-strength? If so, can you provide details?
> Suspect, to the extent that it should not be used? Should it be built
> against a newer cracklib? Note that we're using it with MIT kerberos,
> so hopefully this isn't off-topic for this list.
The code quality of CrackLib (any version) has historically not been very
good. I fixed a bunch of corruption bugs in the version embedded in
krb5-strength compared to the (at the time) abandoned upstream. But since
then someone else took over upstream development and found more bugs. I
have mail somewhere in my inbox about them, but I haven't looked at them
in any detail for security implications. (Since switching jobs, I haven't
been doing much with Kerberos, and haven't had time to chase down a lot of
things like that.)
The concern for MIT is stronger because it runs directly inside kadmind,
so any sort of bug might have immediate security implications. If you
have a fairly recent distribution with the new patches, you may want to
consider building with system CrackLib instead, or downloading the current
version of CrackLib and installing it and then telling krb5-strength that
it's the system version and to build with it. You do lose some of the
patched-in rules, though.
Alternately, you may want to consider switching to the SQLite database
approach with a good wordlist. It doesn't do all the complex munging that
CrackLib does, but current thinking on password strength is that those
munging rules aren't as useful as they used to be. It does generic edit
distance one checks from any dictionary word, which we found to be pretty
That said, I may be excessively paranoid, since I did hack on the embedded
CrackLib until it ran clean under valgrind. That doesn't mean there are
no remaining bugs, but I may have already patched or worked around those
I'm hoping to find some time over the upcoming long US holiday weekend to
try to catch up on some open source stuff.
Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>