[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: use_authtok -- what purpose?



Jan Rekorajski wrote:
> 
> On Thu, 06 Apr 2000, Michael Tokarev wrote:
> 
> > I'm now in process of modifiyng pam_cracklib. And it should have configurable
> > oldpass file (not only /etc/opasswd, but with default on this).
> > I want pam_saveoldpass to be the next thing (also with configurable path).
> 
> Hmm, if there will be a saveoldpass module then sticking the same code around
> other modules is, IMHO, pointless.  Clean way would be to remove the code in
> question from pam_{unix,cracklib,*} and just tell people to use pam_saveoldpass.
> And leave only check for old password in these modules.

No, I do not think so.  Cracklib will check password quality, and _look_ to oldpass,
if desired, for this.  But saveoldpass shoud just _save_ old password, and not to check
it in any way.  If we have, say, pam_storepass (be it pam_unix, pam_pwdb, pam_smb etc etc),
that stores new password in it's well-known location, and makes also auth using that password,
then we should have:

   pam_newpass - ask new password, verify quality etc
   pam_storepass - saves it in it's place
   pam_saveoldpass (always return success) - save _old_ password for use by pam_newpass

If we exchange storepass<=>saveoldpass, than newpass+saveoldpass can be combined
to one general-use module.  But with this, we have:

   pam_newpass - ask new password, verify quality etc and saves old in some file
   pam_storepass - saves it in it's place; but failed for some reason

With this, old password (that is current after fail) already stored in opasswd,
and can be stolen from there (since there is less attention for it's security).
So we _must_ save old password only _after_ storing the new one in place.

With this scheme as I want, we can safely remove password quality checking code
from all other modules, including opasswd things.  And make those far more
simple/generic, and let them do their tasks (storing/verifying) better.

Regards,
  Michael.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []