password quality script aka --with-cracklib replacement

[Martin Pool]

On 12 Feb 2003, Andrew Bartlett <abartlet at samba.org> wrote:

> Because we don't have the old password, doing this via PAM doesn't
> work.  The pam_cracklib module doesn't apply the test if it's run as
> root, and won't run without the old password as a normal user.

I know it won't work with the existing pam_cracklib module.  What I was
asking was whether it is possible to write a new module that connects
using PAM and which does provide the right checks, rather than
inventing a new plugin interface.

The PAM module might store previous passwords in a database (e.g. tdb)
that it maintains.  Every time a password is set, it gets put in
there, with any other appropriate information (date?).  When a new
password-setting attempt is made, it checks against the history, plus
other strength checks.

I know PAM's configuration method is a bit gross, but "standard is
better than better."

Since libraries can't be setuid it would need to be invoked by smbd as
root, but that probably make sense anyhow as you say.

> > Personally I would use something like a tdbpacked string, which avoids
> > worries about strange characters or string parsing, and is easy to
> > handle in C, Perl, and Python.
> 
> This is an interesting idea - but how available is the interface for our
> particular custom string format?

There is a Python library to decode them.  Writing one for Perl would
be quite trivial: perhaps 100 lines and half an hour.

> > >           NT_STATUS_OK # New password accepted
> > > 
> > >           NT_STATUS_ACCESS_DENIED # Error occured in the script
> > > 
> > >           NT_STATUS_PASSWORD_RESTRICTION # Too short,  weak, etc.
> 
> I suggested the string - I don't think sending the hex value adds much,
> and makes it less self-documenting.  Parsing the string is trivial, as
> we already have the lookup routines (I use it for a custom-hack auth
> module).  We could certainly allow both - which would allow a new
> NTSTATUS code to be used in the unlikely event a useful one appears in
> this context.

You can perhaps imagine a script that wants to be a proxy to some
other service that returns arbitrary error codes,  so translating to
and from strings would be a waste of time and effort.  So we ought to
at least allow numeric values, as you say.

Why make it optional, though?  There's already space for a
human-readable description string.  Presumably the script will use
symbolic names for all the values, so the code will be
self-documenting which is the most important part.

All these protocols send numeric values, so it's better to be
consistent.  (For example, wbinfo prints out hex ntstatus values.)

-- 
Martin