[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: pam_crypt module will change the world



> 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





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []