- krb5-strength 2.2
+ krb5-strength 3.0
(Kerberos password strength checking plugin)
Maintained by Russ Allbery <eagle@eyrie.org>
- Copyright 2006, 2007, 2009, 2010, 2012, 2013 The Board of Trustees of
- the Leland Stanford Junior University. Portions copyright 1993 Alec
+ Copyright 2006, 2007, 2009, 2010, 2012, 2013, 2014 The Board of Trustees
+ of the Leland Stanford Junior University. Portions copyright 1993 Alec
Muffett. Developed by Derrick Brashear and Ken Hornstein of Sine Nomine
Associates, on behalf of Stanford University. This software is
distributed under a BSD-style license and under the Artistic License.
krb5-strength provides a password quality plugin for the MIT Kerberos
KDC (specifically the kadmind server), an external password quality
- program for use with Heimdal, and a password history implementation for
- use with Heimdal. Passwords can be 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 particular character classes,
- or any combination of these tests. It supports both Heimdal and MIT
- Kerberos (1.9 or later).
+ program for use with Heimdal, and a per-principal password history
+ implementation for Heimdal. Passwords can be tested with CrackLib,
+ checked against a CDB or SQLite database of known weak passwords with
+ some transformations, checked for length, checked for non-printable or
+ non-ASCII characters that may be difficult to enter reproducibly,
+ required to contain particular character classes, or any combination of
+ these tests. It supports both Heimdal and MIT Kerberos (1.9 or later).
DESCRIPTION
that only passes passwords that resist attacks from both Crack and Jack
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.
+ dictionaries, or a SQLite database, which can reject all passwords
+ within edit distance one of a dictionary word. It can also impose 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
You can also optionally build against the TinyCDB library, which
provides support for simpler and faster password checking against a CDB
- dictionary file.
+ dictionary file, and the SQLite library (a version new enough to support
+ the sqlite3_open_v2 API; 3.7 should be more than sufficient), which
+ provides support for checking whether passwords are within edit distance
+ one of a dictionary word.
For this module to be effective for either Heimdal or MIT Kerberos, you
will also need to construct a dictionary. The mkdict and packer
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. cdbmake-wordlist
- requires Perl 5.006 or later.
+ For building a CDB or SQLite dictionary, use the provided
+ krb5-strength-wordlist program. For CDB dictionries, the cdb utility
+ must be on your PATH. For SQLite, the DBI and DBD::SQLite Perl modules
+ are required. krb5-strength-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
To run the test suite, you will need Perl 5.010 or later and the
dependencies of the heimdal-history program. The following additional
- Perl modules will be used by the test suite if present:
+ Perl modules will also be used by the test suite if present:
Perl6::Slurp
Test::MinimumVersion
Test::Spelling
Test::Strict
- All are available on CPAN. Those tests will be skipped if the modules
+ All are available on CPAN. Some tests will be skipped if the modules
are not available.
- To enable tests that may be sensitive to the local environment or that
- produce a lot of false positives without uncovering many problems, set
- RRA_MAINTAINER_TESTS to a true value.
+ To enable tests that don't detect functionality problems but are used to
+ sanity-check the release, set the environment variable RELEASE_TESTING
+ to a true value. To enable tests that may be sensitive to the local
+ environment or that produce a lot of false positives without uncovering
+ many problems, set the environment variable AUTHOR_TESTING to a true
+ value.
To bootstrap from a Git checkout, or If you change the Automake files
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. 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.
+ later and the DBI, DBD::SQLite, JSON, Perl6::Slurp, and Readonly modules
+ (from CPAN) to bootstrap the test suite data from a Git checkout.
COMPILING AND INSTALLING
also separately set the include and library path with
--with-tinycdb-include and --with-tinycdb-lib.
+ Similarly, krb5-strength will automatically build with SQLite if it is
+ found. To specify the installation path of SQLite, use --with-sqlite.
+ You can also separately set the include and library path with
+ --with-sqlite-include and --with-sqlite-lib.
+
Normally, configure will use krb5-config to determine the flags to use
to compile with your Kerberos libraries. If krb5-config isn't found, it
will look for the standard Kerberos libraries in locations already
CONFIGURATION
First, build and install either a CrackLib dictionary as described in
- REQUIREMENTS above, or build a CDB dictionary with cdbmake-wordlist.
- (Or both.) The CrackLib dictionary will consist of three files, one
- each ending in *.hwm, *.pwd, and *.pwi. The CDB dictionary will consist
- of a single file ending in *.cdb. Install those files somewhere on your
- system. Then, follow the relevant instructions below for either Heimdal
- or MIT Kerberos.
+ REQUIREMENTS above, or build a CDB or SQLite dictionary with
+ krb5-strength-wordlist. (Or any combination thereof.) The CrackLib
+ dictionary will consist of three files, one each ending in *.hwm, *.pwd,
+ and *.pwi. The CDB and SQLite dictionaries will be single files,
+ conventionally ending in *.cdb and *.sqlite respectively. Install those
+ files somewhere on your system. Then, follow the relevant instructions
+ below for either Heimdal or MIT Kerberos.
See "Other Settings" below for additional krb5.conf setting supported by
both Heimdal and MIT Kerberos.
file is located):
krb5-strength = {
- password_dictionary = /path/to/cracklib/dictionary
- password_dictionary_cdb = /path/to/cdb/dictionary.cdb
+ password_dictionary = /path/to/cracklib/dictionary
+ password_dictionary_cdb = /path/to/cdb/dictionary.cdb
+ password_dictionary_sqlite = /path/to/sqlite/dictionary.sqlite
}
- The first setting configures a CrackLib dictionary and the second a CDB
- 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. 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 first setting configures a CrackLib dictionary, the second a CDB
+ dictionary, and the third a SQLite 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
+ any combination of the three settings. If you use more than one,
+ CrackLib will be checked first, then CDB, and then SQLite as
+ appropriate.
+
+ When checking against 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.
+
+ When checking a SQLite database, the password will be rejected if it is
+ within edit distance one of any word in the dictionary, meaning that the
+ database word can be formed from the password by deleting, adding, or
+ changing a single character.
Then, for the external password checking program, add a new section (or
modify the existing [password_quality] section) to look like the
[appdefaults] section:
krb5-strength = {
- password_dictionary = /path/to/cracklib/dictionary
- password_dictionary_cdb = /path/to/cdb/dictionary.cdb
+ password_dictionary = /path/to/cracklib/dictionary
+ password_dictionary_cdb = /path/to/cdb/dictionary.cdb
+ password_dictionary_sqlite = /path/to/sqlite/dictionary.sqlite
}
- The first setting configures a CrackLib dictionary and the second a CDB
- 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. 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 first setting configures a CrackLib dictionary, the second a CDB
+ dictionary, and the third a SQLite 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
+ any combination of the three settings. If you use more than one,
+ CrackLib will be checked first, then CDB, and then SQLite as
+ appropriate.
+
+ When checking against 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.
+
+ When checking a SQLite database, the password will be rejected if it is
+ within edit distance one of any word in the dictionary, meaning that the
+ database word can be formed from the password by deleting, adding, or
+ changing a single character.
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
dictionary matching.
You can also mix and match these settings, by using dict_path for the
- CrackLib dictionary path and krb5.conf for the CDB dictionary path. If
- both settings are used, krb5.conf overrides the dict_path setting (so
- that dict_path can be used for other password quality modules). There
- is no way to specify a CDB dictionary via the dict_path setting.
+ CrackLib dictionary path and krb5.conf for the CDB or SQLite dictionary
+ paths. If both settings are used for the CrackLib path, krb5.conf
+ overrides the dict_path setting (so that dict_path can be used for other
+ password quality modules). There is no way to specify a CDB or SQLite
+ dictionary via the dict_path setting.
Other Settings
The krb5-strength package as a whole is covered by the following
copyright statement and license:
- Copyright 2006, 2007, 2009, 2010, 2012, 2013
+ Copyright 2006, 2007, 2009, 2010, 2012, 2013, 2014
The Board of Trustees of the Leland Stanford Junior University
Permission is hereby granted, free of charge, to any person obtaining
projects / kerberos / krb5-strength.git / blobdiff