[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)

[Kees Cook]

On Mon, Apr 06, 2009 at 06:59:01AM +0200, Nicolas François wrote:
> 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

Ah, yes, you seem to be right about salt -- it is handled.  However,
there is still the case of choosing the system-configured hash method.

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

What are your thoughts on how to detect what PAM has configured as the
default hash method for pam_unix.so?

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

Right, my concern was the length of the salt -- it depends on the hash
method.  However, it seems that mkpasswd handles this.  (Why is this tool
in "whois"?!)

Speaking for randomness, I think mkpasswd is totally wrong:
    srand(time(NULL) + getpid());

This needs to at least use /dev/urandom, or sec+usec as done in shadow.

I don't feel that mkpasswd is a viable replacement.

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

Right, this is only sane for supported hashing methods, but PAM tracks
glibc in this regard, so I'm not worried.

-- 
Kees Cook                                            @debian.org