Re: xlock (was Re: libcrypt info)

[Elliot Lee <sopwith redhat com>]

On Wed, 12 Jun 1996, Marek Michalkiewicz wrote:

> But pam_unix_md5 has to be compatible with traditional DES passwords
> too - so it could well always be used instead of pam_unix, and thus
> renamed to pam_unix :-).  The situation here is similar to pam_unix
> vs. pam_shadow (or, as I prefer to call them, pam_v7 vs. pam_unix).
> There may be several password hashing algorithms, but it's still
> basically the same authentication method.
> 
> > as to whether one can constuct messages for 'any' given MD5 digest
> > turns out to be real.. (see news:sci.crypt for more info) RIPEMD-160
> 
> It wouldn't be good, MD5 is so widely used and trusted...  The new
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Widely used, most likely, but not so trusted anymore; read sci.crypt for
info. How about giving the option of UNIX crypt, MD5, or SHA?  But I
guess that is what PAM is all about - allowing people to plug in new
modules easily.

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)?

> MD5-based crypt() came from FreeBSD - we'll see what they will do
> when MD5 turns out to be weak.  But it may still be hard to break
> because it's not just one MD5 hash, it is iterated many times to
> slow things down.
> 
> At least the new format allows for different magic strings for
> different algorithms, so adding a new one in a backward-compatible
> way shouldn't be too difficult.

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

\\\| Elliot Lee                |\\\    ||  "Claim to fame":
 \\\| Red Hat Software          |\\\   ||  Live in only town in the
  \\\| Webmaster www.redhat.com, |\\\  ||  USA with an unlisted ZIP
   \\\| Programmer, etc.          |\\\ ||  code.