> I'm personally of the opinion that supporting multiple algorithms is an > advantage, because it opens up the possibility of gaining mindshare with > administrators of other operating systems for whom backwards-compatibility > with alternative 'secure' password hashes is a prerequisite. Yeah. At this current moment I am coding a algorithm module for bcrypt based on solar designer's crypt_blowfish-0.3 implementation. Hopefully I will have it done before 2:00 am... As miah (jokingly) said.. "make bcrypt available because people should migrate from openbsd to linux." hehe :) > Does the ability to specify alternate locations for the password file come at > the expense of being able to use the system getpwnam() call (and therefore > make use of other NSS backends), or have you balanced both of these > requirements in a single module? Unfortunatly, yes. That was a sacrafice I decided to make. I don't use any of the standard libc calls for interfacing to a password file at the moment. I knew this would probably be a source of flames, but I decided to do it anyway. I've been thinking about doing "both" at the same time where the administrator could select which one to use with an option in the pam.d service file. Now that I've had somebody request this (or mention it..), I will probably implement it. This is not a priority, however, and may not be added for a little while. So in short, it does come at the expense of not using NSS, but in the future it will be well balanced with the best of both worlds. Thanks, Adam Slattery
