tested with CrackLib, checked against a CDB database of known weak
passwords, checked for length, checked for non-printable or non-ASCII
characters that may be difficult to enter reproducibly, required to
- contain a non-alphabetic character, or any combination of these tests.
+ contain particular character classes, or any combination of these tests.
It supports both Heimdal and MIT Kerberos (1.9 or later).
DESCRIPTION
checks and comes with an example that checks passwords against CrackLib.
However, in testing at Stanford, we found that CrackLib with its default
transform rules does not catch passwords that can be guessed using the
- same dictionary with other tools, such as Jack the Ripper.
+ same dictionary with other tools, such as Jack the Ripper. We then
+ discovered other issues with CrackLib with longer passwords, such as
+ some bad assumptions about how certain measures of complexity will
+ scale, and wanted to impose other limitations that it didn't support.
This plugin provides the ability to check password quality against the
standard version of CrackLib, or against a modified version of CrackLib
that only passes passwords that resist attacks from both Crack and Jack
- the Ripper using the same rule sets. For Heimdal, it includes both a
- program usable as an external password quality check and a plugin that
- implements the dynamic module API. For MIT Kerberos (1.9 or later), it
- includes a plugin for the password quality (pwqual) plugin API.
+ the Ripper using the same rule sets. It also supports doing simpler
+ dictionary checks against a CDB database, which is fast with very large
+ dictionaries, and imposing other programmatic checks on passwords such
+ as character class requirements.
+
+ For Heimdal, it includes both a program usable as an external password
+ quality check and a plugin that implements the dynamic module API. For
+ MIT Kerberos (1.9 or later), it includes a plugin for the password
+ quality (pwqual) plugin API.
krb5-strength can be built with either the system CrackLib or with the
modified version of CrackLib included in this package. Note, however,
You can also optionally build against the TinyCDB library, which
provides support for simpler and faster password checking against a CDB
- dictionary file. Building a CDB dictionary with cdbmake-wordlist
- (included) requires Perl 5.006 or later and the CDB utility that comes
- with TinyCDB.
+ dictionary file.
For this module to be effective for either Heimdal or MIT Kerberos, you
will also need to construct a dictionary. The mkdict and packer
in this toolkit but not installed by default. You can run them out of
the cracklib directory after building. You can also use the utilities
that come with the stock CrackLib package (often already packaged in a
- Linux distribution); the database format is compatible. For building a
- CDB dictionary, use the provided cdbmake-wordlist program. The CDB
- utility must be on your PATH.
+ Linux distribution); the database format is compatible.
+
+ For building a CDB dictionary, use the provided cdbmake-wordlist
+ program. The CDB utility must be on your PATH. cdbmake-wordlist
+ requires Perl 5.006 or later.
For a word list to use as source for the dictionary, you can use
/usr/share/dict/words if it's available on your system, but it would be
following additional Perl modules will be used by the test suite if
present:
- File::Slurp
IPC::Run
JSON
+ Perl6::Slurp
Test::MinimumVersion
Test::Perl::Critic
Test::Pod
and need to regenerate Makefile.in, you will need Automake 1.11 or
later. For bootstrap or if you change configure.ac or any of the m4
files it includes and need to regenerate configure or config.h.in, you
- will need Autoconf 2.64 or later.
+ will need Autoconf 2.64 or later. You will also need Perl 5.010 or
+ later and the JSON, Perl6::Slurp, and Readonly modules (from CPAN) to
+ bootstrap the test suite data from a Git checkout.
COMPILING AND INSTALLING
dictionary. The provided path should be the full path to the dictionary
files, omitting the trailing *.hwm, *.pwd, and *.pwi extensions for the
CrackLib dictionary. You can use either or both settings. If you use
- both, CrackLib will be checked first, and then CDB.
+ both, CrackLib will be checked first, and then CDB. When checking a CDB
+ database, the password, the password with the first character removed,
+ the last character removed, the first and last characters removed, the
+ first two characters removed, and the last two characters removed will
+ all be checked against the dictionary.
Then, for the external password checking program, add a new section (or
modify the existing [password_quality] section) to look like the
dictionary. The provided path should be the full path to the dictionary
files, omitting the trailing *.hwm, *.pwd, and *.pwi extensions for the
CrackLib dictionary. You can use either or both settings. If you use
- both, CrackLib will be checked first, and then CDB.
+ both, CrackLib will be checked first, and then CDB. When checking a CDB
+ database, the password, the password with the first character removed,
+ the last character removed, the first and last characters removed, the
+ first two characters removed, and the last two characters removed will
+ all be checked against the dictionary.
The second option is to use the normal dict_path setting. In the
[realms] section of your krb5.conf kdc.conf, under the appropriate realm
The character class checks will be done in whatever locale the
plugin or password check program is run in, which will normally be
- the C locale but may be different depending on local configuration.
+ the POSIX C locale but may be different depending on local
+ configuration.
A simple example: