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

Re: use_authtok -- what purpose?



Michael Tokarev wrote:
> But here is more generic issue.
> There are many places where passwords can be stored (/etc/{passwd,shadow},
> .db file, sql database, even remote machine - e.g. NT (!) SAM database etc etc),
> and we need to be shure that user chooses good password regardless on where it
> is stored actually.  And module like pam_cracklib is ok for this purpose.
> So I think we should have one "asking" module (pam_cracklib for example),
> that asks the password and enshures that it is good enouth, and many other
> modules that can be stacked "on top of it" to store password.

If I recall correctly, the way things currently work is as follows:

  we have a stack of 'password' modules: pam_cracklib and then pam_pwdb

The way libpam works is that it calls the 'password' stack twice, once
with PAM_PRELIM_CHECK, and then if it looks like things will be ok, it
calls everything again with PAM_UPDATE_AUTHTOK.

The way we arranged to plug pam_cracklib in was for it to ignore the
PAM_PRELIM_CHECK call. But on the second attempt (PAM_UPDATE_AUTHTOK),
pam_cracklib is responsible for obtaining the new password and verifying
that it is of some quality. This new password is then installed as
PAM_AUTHTOK. To make all this work it is important that pam_pwdb
(substitute your favorite module) not try to prompt for a new password.
If I look at my pam.d/passwd entry it looks like this:

password   required	pam_cracklib.so retry=3
password   required	pam_pwdb.so use_authtok nullok

Note: use_authtok is not an argument to pam_cracklib, but to pam_pwdb.
It is not the same as use_first_pass because it does not relate to
getting the original (current) password which _is_ obtained by pam_pwdb,
but getting the replacement password (which is obtained from the user by
pam_cracklib).

> Also, one good candidate for module is "pam_saveoldpass" that should be stacked
> on top of password storing module and should do the work that pam_unix currently
> does -- store old password in, say, /etc/opasswd, and should be used in conjunction
> with (again) the first "asking" module.

Actually, I think I would probably advocate that pam_saveoldpass (save
PAM_OLDAUTHTOK) would get stacked in the following manner:

password   required	pam_cracklib.so retry=3
password   requisite	pam_saveoldpass.so
password   required	pam_pwdb.so use_authtok nullok

and this new module would only pay attention to the PAM_UPDATE_AUTHTOK
phase. In that phase it would verify that the PAM_AUTHTOK was not a
previously saved password, and install a callback to actually save the
current PAM_OLDAUTHTOK value in the opassword file. The callback would
be the cleanup thing for some pam_[gs]et_data() object. Recall that this
cleanup function gets called with the pam_end() status code, so based on
that value (PAM_SUCCESS or not) it could make a sensible decision about
whether the new PAM_AUTHTOK was accepted or not and hence whether it was
appropriate to add the old one to the opasswd file.

[I've not paid much attention to the opasswd thing, so I may be
confusing OLDAUTHTOK with AUTHTOK in the above.. But I think the PAM
aspect of the argument is the same if you s/OLD//g above.]

> With the current situation, there are a lot of password checking spread across
> pam_pwdb, pam_unix etc, and all of them uses different approaches.
> 
> Hence, for pam_cracklib-like module, is it even ok to have use_first_pass or
> use_authtok at all?!  Try_first_pass sounds good, but the rest is not clean
> to me. Especially if we have no mechanism of "popping" back modules (module
> "stack"), i.e. we have no ability to "recall" previous module...

Doing strings on pam_cracklib.so from my (archaic) Red Hat 6.1 system, I
don't see "use_firstpass" at all, I don't believe its use was part of
the original design for this module.

Cheers

Andrew



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