Solar Designer wrote: > > This is fine with me. In fact, you could want to drop the md5 flag > as well and switch to the syntax I'm using in my patched pam_pwdb, > which looks like: > > 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. > Ideally, the PAM module should know nothing about these or other > supported hash types. It shouldn't know how to process the prefix or > the count, -- these are to be passed into crypt_gensalt in libcrypt. > This is how things work on my systems (well, those that have PAM at > all). However, as your module shouldn't depend on a particular libc, > you should probably provide the ability to generate salts for the > traditional (you call it plain) and MD5-based hashes (but not the > password hashing code itself), this should be about 2 KB of source in > a separate source file. -- Tom Wu Principal Software Engineer Arcot Systems (408) 969-6124
