<HEAD><TITLE>discuss@charon: [1043] in "Coldmud discussion meeting"</TITLE>
<H1>[1043] in Coldmud discussion meeting</H1></HEAD>
<A HREF="/"><IMG SRC="/i-d.gif" ALT="root"></A>
<A HREF="?1043"><IMG SRC="/i-back.gif" ALT="meeting"></A>
<A HREF="/help.html"><IMG SRC="/i-help.gif" ALT="help"></A>
<A HREF="1"><IMG SRC="/i-first.gif" ALT="first"></A>
<A HREF="1042"><IMG SRC="/i-fref.gif" ALT="first in chain"></A>
<A HREF="1042"><IMG SRC="/i-pref.gif" ALT="previous in chain"></A>
<A HREF="1042"><IMG SRC="/i-prev.gif" ALT="previous"></A>
<A HREF="1044"><IMG SRC="/i-next.gif" ALT="next"></A>
<A HREF="1044"><IMG SRC="/i-nref.gif" ALT="next in chain"></A>
<A HREF="1045"><IMG SRC="/i-lref.gif" ALT="last in chain"></A>
<A HREF="1641"><IMG SRC="/i-last.gif" ALT="last"></A>
<HR><H2>Re: [COLD] An alternative to common crypt() handling.</H2>
<H3>daemon@ATHENA.MIT.EDU (Wed Jul 24 17:55:09 1996
)</H3>
<PRE>
Date: Wed, 24 Jul 1996 16:26:31 -0500 (CDT)
From: Brad Roberts &lt;braddr@puremagic.com&gt;
To: Brandon Gillespie &lt;brandon@tombstone.sunrem.com&gt;
cc: coldstuff@cold.org
In-Reply-To: &lt;Pine.BSF.3.91.960724121737.25548A-100000@tombstone.sunrem.com&gt;

All well and good.. but how does this fix the cross platform 
transportability  of the still encrypted passwords?

On Wed, 24 Jul 1996, Brandon Gillespie wrote:

&gt; Correct me if I'm wrong, but 'crypt()' exists for one purpose, and that 
&gt; is handling passwords.  What I suggest is taking a step towards greater 
&gt; abstraction by adding two things:
&gt; 
&gt;   * a match_crypted() builtin.
&gt;   * a encrypted data type.
&gt; 
&gt; The key is the encrypted data type's literal representation would be:
&gt; 
&gt;     "ENCRYPTED"
&gt; 
&gt; The only way to create encrypted data would be through 'crypt()'.  When
&gt; matching encrypted data you would pass it to 'match_crypted()'.  The only 
&gt; time the actual true value of the encrypted data would be seen is in a
&gt; text dump, at which point it would be whatever is behind the scenes (such 
&gt; as DES or MD5 or whatever).
&gt; 
&gt; This has two advantages:
&gt; 
&gt;   * Abstracting with match_crypted() means you dont have problems when
&gt;     different implementations store the seed in different locations
&gt;     (such as FreeBSD and MD5).
&gt;   * Security is heightened as only people with login access to the
&gt;     filesystem can even see the true value of a password.
&gt; 
&gt; Basically, its like creating shadow passwords in unix..
&gt; 
&gt; Comments?
&gt; 
&gt; -Brandon Gillespie
&gt; 
</PRE>
