On Mon, Apr 06, 2009 at 06:59:01AM +0200, Nicolas François wrote: > On Sun, Apr 05, 2009 at 06:03:56PM -0700, k...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org