[Pkg-shadow-devel] Bug#505640: closed by Nicolas François <nicolas.francois at centraliens.net> (Re: Bug#505640: generate hashed passwords to stdout for other tools)

[Kees Cook]

Hi,

On Sun Apr 5, 2009, Nicolas François said:
> On Thu, Nov 13, 2008 at 04:43:51PM -0800, Kees Cook wrote:
> > 
> > There are situations where a non-root user needs to generate an encrypted
> > password using the current system configuration (i.e. following the
> > settings in /etc/login.defs).  As an example, liboobs passes an encrypted
> > password to system-tools-backends which then calls "chpasswd -e".
> 
> This feature is provided by mkpasswd.

I don't agree with this -- mkpasswd takes a salt as an input, which means
knowledge of the salt must be external to mkpasswd.  For tools like
system-tools-backends, there needs to be an agnostic way to generate a
hashed password (including salt) from a given plain text.

> > To avoid 3rd party re-implementations of the salt-generation and system
> > configuration parsing, it would be handy to have a tool part of shadow that
> > handled this and produced a hashed password on stdout.
> 
> Generating a password looks really different from the intent of chpasswd.
> Also ideally, chpasswd should not generate passwords on a Debian system,
> as password should be generated by PAM.

While certainly true, there is still a need external to PAM, for
this utility.  By this rationale, /etc/login.defs should not include
ENCRYPT_METHOD or any other crypt/hash-related knowledge, and chpasswd,
gpasswd, and newusers should not exist in the shadow package.  However,
in reality, the shadow package is basically the user-space front-end
to the glibc crypt function, and one of the primary uses of the crypt
front-end is the creation of initial passwords (as done in newusers).

There is a general need for an interface to the routines that newusers and
chpasswd use to produce a hashed password.  Forcing this to be
reimplemented in other software is just asking for problems.  Perhaps my
specific patch to chpasswd is not the best way to get there, but I think
some mechanism needs to exist, and it seems that the logical place for it
is in the shadow package.

What would you suggest as a viable interface that system-tools-backends
(and others) could use to safely and consistently generate hashed
passwords conforming to the system-configured preferred hashing routine?
(Note that such passwords are not strictly designed to live in PAM --
web sites could be storing login credentials in a database, but want to
use a strong hash.)

Thanks,

-Kees

-- 
Kees Cook                                            @debian.org