Date: Thu, 29 Aug 1996 14:23:43 -0600 (MDT) From: Brandon Gillespie <brandon@tombstone.sunrem.com> To: hackers@FreeBSD.org Subject: Re: 'Backwards' DES support for crypt(), while still using better , algo's Message-ID: <Pine.BSF.3.91.960829141415.17864A-100000@tombstone.sunrem.com> In-Reply-To: <199608291906.NAA07417@rocky.mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> >
> > Sorry, I was not very clear :) What I'm suggesting is something different
> > from the secure distribution which gives you 'DES capability' while still
> > also having the capability of different encryption algorythms. It would
> > do this with a DES version '$0$' which would hook the encryption into DES
> > encrypt, where '$1$' would still hook into MD5 and '$2$' would hook into
> > SHA-1 (my code for crypt hooks into MD5/SHA-1 already, based off which
> > version you pass it in the salt), and not placing a version in the salt
> > would hook into the 'default' that crypt is using. This leaves it up to
> > crypt() to handle the default version, when newer and better algorythms
> > are added--without having to change passwd and all other relevant
> > programs.
>
> Except that this new password file is now FreeBSD-centric, and can't be
> shared with any other system. Simply adding a new 'token' for the SHA-1
> stuff would be fine, but by changing what DES looks like is asking for
> trouble.
The password file is already FreeBSD-centric, you cannot drop back to a
DES only (or Version 7) file with MD5/SHA passwords scattered through it.
Basically I was hopeing to make it more modular, so programs such as
passwd wouldn't have to code in acceptance of '$x$' like they do right
now. However, in order to do this the default behaviour of crypt()
should be the most preferred encryption scheme (SHA-1 etc), not the
oldest (DES), which it would have to be if DES passwords were not flagged
as such. An outline of the behaviour I'm thinking of is:
When crypt is called examine salt, hook into specific crypt based off
'$x$' version, otherwise assume most preferred method of encryption if
salt is not specified. This allows you to have DES passwords next to
MD5, SHA and other passwords by prefixing them with '$0$' and refining
the salt from the DES password appropriately.
The most common way to test a password is to simply do:
!strcmp(crypt(possible_word, current_passwd))
The problem is that if DES passwords stay as they are, it will do MD5
encryption on the possible word, using the DES password as the salt (as it
does right now, if you try to put DES passwords in with an MD5 file).
-Brandon Gillespie
On another note, I also have a thread_crypt() that does not use a static
buffer (it mallocs the encrypted word).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.960829141415.17864A-100000>