[1043] in Coldmud discussion meeting

Re: [COLD] An alternative to common crypt() handling.

daemon@ATHENA.MIT.EDU (Wed Jul 24 17:55:09 1996 )

Date: Wed, 24 Jul 1996 16:26:31 -0500 (CDT)
From: Brad Roberts <braddr@puremagic.com>
To: Brandon Gillespie <brandon@tombstone.sunrem.com>
cc: coldstuff@cold.org
In-Reply-To: <Pine.BSF.3.91.960724121737.25548A-100000@tombstone.sunrem.com>

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:

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