[ There's something seriously broken with pam-list. I'm receiving lots of duplicates of old posts. However, it's the first time I've received the one I'm replying to. ] [ I've changed the subject as we've been discussing too many topics under the old one ("2nd Qs: proposed description of new pam_unix"). ] > > prefix= -- will use the traditional DES-based hashes > > prefix=xy -- the same (could use any valid salt) > > prefix=$1$ -- FreeBSD-style MD5-based hashes (replaces "md5") > > prefix=_ count=100001 -- BSDI/FreeSec extended/"new-style" DES-based hashes > > prefix=$2a$ count=8 -- OpenBSD-style Blowfish-based hashes > > The only suggestion I'd make would be to ensure that the SHA-1 based EPS > hashes were also properly supported, as they are starting to see wide > use. I'd be willing to help with the integration. Do you suggest that we support EPS hashes within the same PAM module? If yes, do you also suggest that we support them within the libcrypt interface I've proposed (and implemented as a glibc/libcrypt patch)? The latter would imply that we implement an equivalent of t_makepwent() within crypt(3) in libcrypt. Let me also suggest something: stop using non-iterated SHA-1 hashes before they're used any wider. Use a modern iterated hash intended for passwords instead. It would be best to use crypt(3) available on the system, and let the administrator choose the hashing method (with a prefix/count pair). With the SHA-1 hashes, I'd rather avoid using SRP/EPS on my systems. Signed, Solar Designer