Ubuntu Manpage: heimdal-strength - Heimdal password quality check embedding CrackLib

NAME

       heimdal-strength - Heimdal password quality check embedding CrackLib

SYNOPSIS

       heimdal-strength [principal]

DESCRIPTION

heimdal-strength is an external password quality check program for Heimdal that verifies the strength of
a password. 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 is normally run via kpasswdd(8) using the Heimdal password quality check interface rather than
directly.

To use this program, it must be configured in krb5.conf via settings in "[appdefaults]" for the
application name "krb5-strength". A typical setting would be:

krb5-strength = {
password_dictionary = /usr/local/lib/kadmind/dictionary
}

which says to check passwords with CrackLib using the given path as the base path of the CrackLib
dictionary. See "CONFIGURATION" below for details on the supported configuration options.

heimdal-strength then expects the Heimdal password quality check information on standard input,
specifically:

principal: <principal>
new-password: <password>
end

where <principal> is the principal whose password would be changed and <password> is the new password.
If the password appears to be strong, it prints "APPROVED" on standard output and exits with a status of
0. If the password is rejected as being too weak, it will print the reason for rejecting the password on
standard error and exit with a status of 0. If some fatal error occurs, it will print that error to
standard error and exit with a non-zero status.

CONFIGURATION

The following krb5.conf configuration options are supported:

cracklib_maxlen
Normally, all passwords are checked with CrackLib if a CrackLib dictionary is defined. However,
CrackLib's rules were designed for a world in which most passwords were four to eight characters
long, and tends to spuriously reject a lot of passphrases. If this option is set to something other
than its default of 0, passwords longer than that length bypass CrackLib checks. (Using a SQLite
dictionary for longer passwords is strongly recommended.)

minimum_different
If set to a numeric value, passwords with fewer than this number of unique characters will be
rejected. This can be used to reject, for example, passwords that are long strings of the same
character or repetitions of small numbers of characters, which may be too easy to guess.

minimum_length
If set to a numeric value, passwords with fewer than that number of characters will be rejected,
independent of any length restrictions in CrackLib. Note that this setting does not bypass the
minimum length requirements in CrackLib itself.

password_dictionary
Specifies the base path to a CrackLib dictionary and enables password strength testing using
CrackLib. The provided path should be the full path to the dictionary files, omitting the trailing
*.hwm, *.pwd, and *.pwi extensions for the CrackLib dictionary.

password_dictionary_cdb
Specifies the base path to a CDB dictionary and enables CDB password dictionary lookups. The path
must point to a CDB-format database whose keys are the known passwords or dictionary words. The
values are ignored. You can use the krb5-strength-wordlist utility to generate the CDB database from
a word list.

The CDB dictionary lookups do not do the complex password mangling that CrackLib does. Instead, the
password itself will be checked against the dictionary, and then variations of the password formed by
removing the first character, the last character, the first and last characters, the first two
characters, and the last two characters. If any of these strings are found in the CDB database, the
password will be rejected; otherwise, it will be accepted, at least by this check.

A CrackLib dictionary, a CDB dictionary, and a SQLite dictionary may all be configured at the same
time or in any combination, in which case CrackLib will be run first, followed by CDB and then SQLite
as appropriate.

password_dictionary_sqlite
Specifies the base path to a SQLite dictionary and enables SQLite password dictionary lookups. The
path must point to a SQLite 3 database with a table named "passwords". This table should have two
columns, "password" and "drowssap", which, for each dictionary word, holds the word and the reversed
form of the word. You can use the krb5-strength-wordlist utility to generate the SQLite database
from a word list.

The SQLite dictionary lookups do not do the complex password mangling that CrackLib does, but they
will detect and reject any password that is within edit distance one of a word in the dictionary,
meaning that the dictionary word can be formed from the password by adding, deleting, or modifying a
single character.

require_ascii_printable
If set to a true boolean value, rejects any password that contains non-ASCII characters or ASCII
control characters. Spaces are allowed; tabs are not (at least assuming the POSIX C locale). No
canonicalization or character set is defined for Kerberos passwords in general, so you may want to
reject non-ASCII characters to avoid interoperability problems with computers with different default
character sets or Unicode normalization forms.

require_classes
This option allows specification of more complex character class requirements. The value of this
parameter should be one or more whitespace-separated rule. Each rule has the syntax:

[<min>-<max>:]<class>[,<class>...]

where <class> is one of "upper", "lower", "digit", or "symbol". The symbol class includes all
characters other than alphanumeric characters, including space. The listed classes must appear in
the password. Separate multiple required classes with a comma (and no space).

The character class checks will be done in whatever locale the plugin or password check program is
run in, which will normally be the POSIX C locale but may be different depending on local
configuration.

A simple example:

require_classes = upper,lower,digit

This requires all passwords contain at least one uppercase letter, at least one lowercase letter, and
at least one digit.

If present, <min> and <max> specify the minimum password length and maximum password length to which
this rule applies. This allows one to specify character class requirements that change with password
length. So, for example:

require_classes = 8-19:upper,lower 8-15:digit 8-11:symbol

requires all passwords from 8 to 11 characters long contain all four character classes, passwords
from 12 to 15 characters long contain upper and lower case and a digit, and passwords from 16 to 19
characters long contain both upper and lower case. Passwords longer than 20 characters have no
character class restrictions. (This example is probably used in conjunction with minimum_length =
8.)

require_non_letter
If set to a true boolean value, the password must contain at least one character that is not a letter
(uppercase or lowercase) or a space. This may be helpful in combination with passphrases; users may
choose a stock English phrase, and this will force at least some additional complexity.

AUTHOR

       Russ Allbery <eagle@eyrie.org>

COPYRIGHT AND LICENSE