password quality script aka --with-cracklib replacement

[Martin Pool]

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

> > a) If we want the password-quality script to handle this,
> >     I think we'll all agree, storing clear text password is really
> >     not a good idea. Perhaps the interface should provide the new
> >     encrypted passwords to the external program -- if administrators
> >     don't have "easy access" to the encrypted password, some will
> >     probably endup use the cleartext one :(
> 
> I think this complicates the issue - smbd would then be involved in key
> management etc - and that just gets messy.

A generally useful interface needs to provide the cleartext password.

(For example, as I mentioned earlier, our domain controller forbids
passwords which have too many characters in common with an earlier
password.  I can't see this in the Domain Controller Security Policy,
but perhaps it's a plug in or configured somewhere else.)

Hopefully we can ship enough standard modules that people won't want
to write random insecure implementations.  But if they want to, they can.

> We already use PAM, and we should use it for all the things it's
> intended to do, but this is not something it was intended to do. 

I really disagree, I think this is exactly the sort of thing PAM is
good for: providing a standard interface for doing
authentication-related things, without needing to invent a new
interface for each.  PAM replaces a pile of little messy solutions and
we should really not add a new custom protocol back in.

Using PAM also allows the code to be reused for passwords changed
through other mechanisms (web interfaces, ...)

> (Because we are not asking it to store the password).

I don't understand this one...  Having PAM modules which check a
proposed password change rather than storing it is absolutely fine --
look at the existing strength-checking systems.

  http://www.kernel.org/pub/linux/libs/pam/modules.html

Basically PAM just provides a standard way of having a little
conversation about a new password.

> > Ain't people moving towards pdb LDAP backend using the included
> > LDAP support in Samba instead of using PAM?
> 
> LDAP and PAM solve different problems.

PAM is the interface from the application to the security module; LDAP
is the database.  It could make sense to have a module which talks PAM
to Samba and stores its data in LDAP.

> > We could add an attribute "password quality runas root (true/false)"
> > in smb.conf .   Should we?

Only add it if you can describe a case where running it as root
wouldn't work.

> > 5) "Protocol"
> > 
> > Do we agree on the following for "version: 1\n"?

I think you should use a PAM API rather than a subprocess.  But if you
insist on a subprocess, I think this is OK.

> The script would only send a different value if it was found that MS was
> using a different value.  Allowing a hexadecimal number is both
> perfectly practical, and solves this little issue.

Yes, please just send the number.

-- 
Martin