On Mon, Apr 06, 2009 at 12:30:49PM -0700, k...@debian.org wrote: > 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: > > > > > > 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?
using pam_chauthtok, with a non-interactive conversation function. I have a patch somewhere if you're interested. > > 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. Those are bugs, which can be reported and fixed. There is also a bug that it does not accept salt smaller than 16 bytes for sha-256 and sha-512. This does not conform to http://people.redhat.com/drepper/SHA-crypt.txt > > 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. PAM supports more than glibc. shadow may support more than glibc in non-PAM mode. The 2 sets may not be identical. Best Regards, -- Nekral -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
