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

Re: xlock (was Re: libcrypt info)



Elliot Lee:
> Widely used, most likely, but not so trusted anymore; read sci.crypt for

OK, I should have said it _was_ trusted... :-(

> info. How about giving the option of UNIX crypt, MD5, or SHA?  But I

Shouldn't be hard to add another algorithm to libcrypt using a new
magic string instead of "$1$".  I guess the FreeBSD folks will do it
soon (now that MD5 is not trusted so much) and we probably should
follow them for compatibility.

> Also, how is NIS/NYS/whatever support going to be integrated into PAM?
> Is the pam_unix module going to just call libc? Or might it actually do
> the NIS work itself (like it should, IMHO, since it is doing the auth)?

Last I heard the original author of NYS was working on a new version
(using dynamic /usr/lib/nss_*.so.1 modules ala Solaris) which will be
integrated in libc.  The pam_unix module can then just call libc,
except one thing: it needs to know how to change passwords from various
sources like files, nis, nisplus (unless the new NYS will also include
code to change them, that would be nice - but Solaris 2.5 passwd seems
to have them simply hardcoded, at least from looking at the output of
"strings /usr/bin/passwd"...).

> Dumb Question: Does the MD5 password encryption have anything akin to the
> salt used in the unix crypt() algorithm? 

Not dumb at all :-).  Yes, it does, it can even be longer than 2 chars.
The encrypted password looks like this:

$1$salt$encrypted

where:
$1$ - magic to recognize this algorithm
salt - 1 to 8 characters of the salt string
encrypted - exactly 22 characters (128 bits, base64 conversion)
 of the MD5 hash proper (after many iterations, to slow things down)

Hope this helps,

Marek



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