password quality script aka --with-cracklib replacement

[Andrew Bartlett]

On Fri, 2003-02-14 at 05:05, Pierre Belanger wrote:
> Hi,
> 
> I started this mail yesterday ... 24h/day is not enough since
> the past few days :(

:-)

> First of all, I forget to state in the documentation that the external
> program also needs to send a ".\n" on a new line after sending the
> "required" fields.
> 
> 
> 1) "Don't use recent password" feature:
> 
> I did not want to focuss on this feature yet but since it came
> up on the list, lets do it ;-) This was actually the next thing
> I thought of doing in terms on contribution to Samba!!!
> 
> 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.

> b) My idea was to incorporate this directly within smbd creating a
>     database, tdb? but I have no clue on the specifications of tdb
>     database -- perhaps I'm writing something really stupid  here :)
>     If it's not possible with tdb, I guess we could use something
>     else. I would be much better, in term of security, to store the
>     old passwords using MD5 or even Blowfish (is it legal to
>     distribute such encryption mechanism in Samba -- I'm thinking
>     of the US encryption law restricting exportation).
>     Any experts around?

This really belongs outside smbd.  Each site will have particular
requirements, and I think it's better that we provide good example
scripts, rather than a fantastically rich interface. 

> I also think that such of "module" requires to remove all data
> from the "old password database" when a user is deleted. Or we
> provide a tool for systems administrators that checks if there
> is still a match between what's in the "old pw db" and the
> "pdb" / smbpasswd file, etc!?! If you have a clue now on how
> to achieve this, great -- otherwise we'll think of this when
> we get there!

Big sites use LDAP.  The Net::LDAP module is quite easy to work with. 
As such, storing the old passwords in the same LDAP record as the user
already has, means that the passwords go when the user does.

> 
> 2) PAM module
> 
> I'll leave this to someone else. I really think PAM rocks but
> if we want to support this new feature on every supported OS
> by Samba, I think we should not go PAM. Is PAM standard on
> all Unix flavors? Will Windows ever support PAM? (Ain't someone
> in this world trying to port Samba to Windows? -- I wouldn't be
> surprised, LOL).

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. 
(Because we are not asking it to store the 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.

> 3) "Failed" script
> 
> Yes, if the script fails to run or return an exit status != 0,
> smbd deny the change request.
> 
> 
> 4) Root / non-root
> 
> We could add an attribute "password quality runas root (true/false)"
> in smb.conf .   Should we?

Just provide good example scripts, that change UID at startup time.

> 5) "Protocol"
> 
> Do we agree on the following for "version: 1\n"?
> 
> - Version starts @ 1
> - Space added ... "Field: value\n" -- External can return
>    with or without a space. I think on the answer we can be
>    a little bit "flexible", is that fine?
> - Send empty string value if a "value" is not available:
>    "Fullname: \n"
> - I agree with Andrew -- "string protocol is much easier to
>    implement / debug". I don't know how the fullname will be
>    passed to the external if there are "funky" characters, I know
>    this is not a problem with the other Fields. Perhaps for
>    release #1 we don't send the "fullname"?
> 
>    If we need some type of "encoding / decoding" mechanism,
>    shouldn't we use something already "very popular". If it's
>    too complicated, people won't use it.

Simply refusing to perform if we have control characters in the
username/fullname/password would be sufficient.

> - Returned NTSTATUS. Allow both string and hex or not?

>    If tomorrow there is a new "return code" available, it will work
>    once it is added in "nterr.h".
> 
>    When I first wrote the documentation I wrote something like:
>    "we suggest that you use one of the following NTSTATUS for this
>    context" but I figured perhaps the protocol should not be
>    flexible. Either when there's a new NTSTATUS for this context,
>    we had it in "nterr.h" and password-quality.c  OR we leave it
>    like it is now, i.e. accept anything defined in "nterr.h".
> 
>    Honestly, I'm still not sure if we should allow both. I know I don't
>    really like the idea of smbd returning something not defined in
>    "nterr.h".

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.

>    True "protocols" always use numeric values. "440 - File not found" !
>    If we have to modify the source code when we need to add a new
>    supported returned value, I think we'd rather just need to add this
>    new "value" in nterr.h and Voila!
> 
> - Password field -- "injection attacks"
> 
>    No answer yet on the message (Password changing - root bug?) I sent
>    yesterday night (today early AU time!!!) on the mailing-list. If
>    control-chars are "illegal" , I'll check for this and return, I guess
>    NT_STATUS_ILL_FORMED_PASSWORD would be appropriate here.

Yep.

> 
> Thank you for your valuable comments. I look forwards to read yours.
> 
> Pierre B.

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20030214/50ad0822/attachment.bin