Password quality pluggable interface scope

[Russ Allbery]

ghudson at MIT.EDU writes:

> Currently, when you change your password, kadmind applies various
> checks:

> 1. It rejects empty passwords.  This is the only check if the
>    principal has no associated policy.

> 2. It checks against the realm's configured dictionary file.

> 3. It checks against elements of the principal name.

> 4. If built with hesiod support (I kind of hope no one does this), it
>    looks up the Hesiod passwd information for each principal component
>    and checks against the GECOS information therein.

> 5. It enforces the minimum length and minimum number of character
>    classes as determined by the password policy.

I think we should be aiming for letting the plugin do 1-4.  I don't think
it makes much sense to give the plugin access to the character class
information stored in the policy as long as the kadmin code still enforces
that check internally.  Anyone writing a custom plugin is likely to have
more sophisticated needs anyway, and configuring the plugin via policy
settings is both very limited and not very attractive given the tiny
amount of information available that way.

> 6. It checks password history against one or more recent keys, and
>    stores a password history entry for the current key set.

Password history management should, IMO, stay internal to the kadmin code
since you've already done the work to integrate a password history
database.

> * The most basic: the module gets access to a krb5 context, the
>   dictionary filename at init time, and the principal name (as a
>   krb5_principal) and new password at check time.  This has similar
>   properties to Russ's interface, allowing checks in the style of
>   (1)-(4).  There are three sub-options here:

>   - Only invoke check method if there's a password policy.
>   - Invoke check method whether or not there's a policy.
>   - Pass a boolean argument indicating whether there's a policy.

I agree with Marcus: pass the name of the policy as a string.  I think
that's the best compromise.

> * The module's check method could also be given access to the password
>   policy structure.  This makes the interface dependent on kadmin.h
>   and kdb.h and thus inherently less stable, but allows checks in the
>   style of (5).

As a plugin author, I'd rather not track that interface and have to know
about those data structures, honestly, at least until such time as they
become a lot more extensible and useful as a place to stash my
configuration settings.

> * The module's check method could be given access to the KDB entry and
>   be allowed to change it.  This allows checks in the style of (6),
>   but provides the least isolation and safety between core code and
>   plugin.

I wouldn't do this.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>