> [Michael said...]
> >[Greg said...]
> 
> >Whenever someone wants an account on one of my machines, they ship me a
> >passwd entry... That way their password can remain the same.  And vice
> >versa. Whenever I get an account on someone else's machine, I ship them
> >my password entry.
> 
> So, not only do you break the ``use different passwords on different machines''

This is a choice for the user. Many people use .rhost files, or equiv systems
which make different passwords as insecure as having one. Also, many
infrastuctures like NIS automate having one password on many machines.
The choice is between paranoia and utility. I choose utility.
(Except for the root passwords :-)

> rule, you also expect all crypt()'s to be identical?  There are other

(Yeesh! I'm starting to talk like Greg! Spending too much time around him...:-)
I sure do expect all crypts to be identical! Crypt has been carefully written
to compile on PCs, Suns, Amigas, HPs, and every other piece of hardware known
to man so that it DOES create the same encrypted text! NIS and most other
account managment/distribution schemes would break without it. Not to mention
using the good old 'crypt' utility rather than PGP. Just ask some of the
people in DES-less countries what breaks for them without DES.

> password schemes out there (Kerberos) which also break the ``standard''
> password entries.

Except that Kerberos is a new ''standard'' defined for a different purpose than
crypt.

> Besides, what does a program need to look at the raw
> password entry for anyhow?  The salt argument to crypt() could flag a MD5
> vs. non-MD5 entry.  There is a limited alphabet allowed as a seed.  Use
> something illegal to the DES crypt to flag a MD5 entry.

For NIS, etc... but for standalone machines it won't break too much.

> I would much prefer using MD5 for passwords.  I'm not so certain the method
> posted here earlier is the best, but I believe MD5 to be much more secure
> than the standard old DES.
  
I'm not a cryptographer, but someone here said MD5 runs faster than DES, and
it would require loops the way DES does. If that's our solution then I don't
think MD5 will be 'much more secure'. I'd rather have an algorithm that ran
once, than one that runs 25 times. Feeding the output back to the input
does defeat some types of lexical analysis, but that gain may be overcome
due to simplicity of the formula. DES may be less secure simple because more
people have spend more time hacking it than MD5.

			David "Make it an option" Maxwell
			david@spinne.web.net