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

[Nicolas François]

Hello,

On Sun, Apr 05, 2009 at 06:03:56PM -0700, kees at debian.org wrote:
> 
> 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.

mkpasswd takes a salt in input if a salt is provided. Otherwise, it just
generates its own salt.
And unless proved otherwise, this salt is as good as shadow's one.

For example:
	echo test | mkpasswd -m SHA-256 -s

> > > 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,

I'm targeting this.

> and chpasswd,
> gpasswd, and newusers should not exist in the shadow package.

They create / change users and/or groups in the passwd, shadow, group,
gshadow and as such are legitimate for shadow.

> 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.

The main functionality of a salt is randomness. I really do not see a
need to standardize this randomness, and the salt from mkpasswd is good
enough for me.

I would not recommend to use the shadow tools to generate hashed password
for algorithm that may not be supported by the authentication system,
which is why I would like to move the ENCRYPT_METHOD configuration out on
PAM enabled systems.

Best Regards,
-- 
Nekral