On Thu, 2003-01-16 at 16:17, John H Terpstra wrote: > Pierre, > > Sounds interesting. Please keep this going as there is a lot of interest > in forced secure password change process.
I certainly agree, as the one who put the comment there in the first place :-). We already have 'min password age', 'must change time' and 'must change now' working. Password history is also worth supporting in Samba, but watch out that you need a long password history and long 'mis password age' before it actually works. Even then, we get password1, password2, password3... unless we store plaintext passwords on disk. > Strongly suggest getting the official sources updated, as you have already > suggested. There should be someone who might want to help get this into > the official code tree. Who knows, might even spawn a security update > cycle. > > - John T. > > On Wed, 15 Jan 2003, Pierre Belanger wrote: > > > Hi all, > > > > Last night I did a "grep -i todo" in the source code, to see > > if I could contribute a little bit more ;-) I found the > > following: > > > > smbd/chgpasswd.c: /* TODO: Add cracklib support here */ > > > > I started working on this last night (using SAMBA_3_0 > > branch) and do have something working (the "configure.in", > > documentation, etc is not done yet). I had to make my own > > "API" to cracklib to make this work because the original API > > uses getuid() and getpwuid() to get the username and fullname > > (gecos). I also found a lot of places in the cracklib code > > that is really not "full-proof". So... in the search for > > a better solution: > > > > Tonight, I checked the "cracklib" included in "npasswd". > > (I found a bug, it's also in the original cracklib!!!) > > There isn't a better "API", still uses getuid()/getpwuid(). Yes - that is a problem. We could cope, and use a 'become_user()' kind of thing, but it's not pretty (particularly as we move aways from a direct posix base, to a more NT abstraction layer). Heimdal kerberos supports 'password quality checking' and their example cracklib checker had such a patch, giving a slightly sane interface. So, while others have noticed, nobody has really got around to fixing it. Sounds like a good time to start. > > If the original cracklib or npasswd's cracklib is a > > good idea for Samba, I'll contact the maintainer for both > > products and see if they agree to "update" their code with > > the new API and also update their download site(s). I have > > the feeling "cracklib original" is quite dead unless there > > is a new maintainer (found nothing on sourceforge / > > freshmeat) and might have better chances with the cracklib > > included in npasswd. > > > > Besides using cracklib for password changing, I thought > > of the following idea. Once "cracklib" is enable, have > > an attribute in smb.conf "force password change = yes". > > Then at logon if the password is found by cracklib, force > > the user to change their password right away. That's for > > Samba 3.0.1 ;-) unless I easily find how to do this! > > If you have other ideas let me know. The problem here is that Samba doesn't have the plaintext password very often - the password change is one of the few places, the rest of the time we use challenge/response systems. But running one of l0phtcrak's products (or similar) over the smbpasswd file will certainly find the dictionary passwords pretty quickly. You can disable them manually from there. > > Do I continue working on this or not? Most certainly. In the meantime, I would not object to such code being added directly to Samba, or this being added to our plugin system - but I'll take comment from the rest of the team on this. Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
signature.asc
Description: This is a digitally signed message part