|
From: Thorsten K. <ku...@su...> - 2008-09-08 08:52:30
|
On Mon, Sep 08, Steve Langasek wrote: > On Thu, Sep 04, 2008 at 09:15:57AM +0200, Thorsten Kukuk wrote: > > I thought again about using the plaintext password and maybe calling > > pam_pwhistory twice in the stack. But in the end I don't think that it > > makes sense. pam_pwhistory makes clearly no sense at all for central > > stored passwords (NIS, LDAP, kerberos), if the password strength > > checking is done on the client. You can always choose another client > > for changing the password, which means you can reuse your old passwords. > > So what stay left are local stored passwords, here we always have > > a crypted password. Or systems uses something else than passwords, > > but then pam_pwhistory is useless, too. > > Given all of this, why does it make sense to split pam_pwhistory into a > separate module at all? What are the other use cases besides pam_unix (or > pam_unix2) for local password stores for which we want to keep a record of > previously-used passwords? Why do we have pam_cracklib as sepearate module and did not put it into pam_unix, too? It is useless for all the above scenaries, too, because you could always change the client which you use to change the password to one which does not do the checks. Compile your own yppasswd or use ldapmodify ... Currently we have password history checking in pam_cracklib and pam_unix, where pam_cracklib only checks but does not store the new password. And from my tests it seems to me the pam_cracklib check does not even work correct and you cannot disable it ... And it is usefull even with remote stored passwords: What I prefer is that the password client only creates a SSL channel to the server and there a daemon is running changing the password on that machine with PAM. So you have always a secure channel over the network, and user cannot workaround password strength checks. Here pam_cracklib and pam_pwhistory are very helpfull. > If this is useful then I don't mind including it, at least. I would object > to removing the password history support from pam_unix, since that becomes > an upgrade/compatibility issue. The on disk file is the same, so all you need to do is on pam package upgrade to remove remember option from pam_unix and add pam_pwhistory before. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Markus Rex, HRB 16746 (AG Nuernberg) |