Date: Thu, 29 Aug 1996 16:36:21 -0600 (MDT) From: Brandon Gillespie <brandon@tombstone.sunrem.com> To: Nate Williams <nate@mt.sri.com> Cc: hackers@freebsd.org Subject: Re: 'Backwards' DES support for crypt(), while still using better , algo's Message-ID: <Pine.BSF.3.91.960829154946.18074B-100000@tombstone.sunrem.com> In-Reply-To: <199608292126.PAA08439@rocky.mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 29 Aug 1996, Nate Williams wrote:
> This is a non-standard case. Most folks have all of one or the other.
Yes, but ONLY because we dont have any other option!
Once again, what I am suggesting is that--WHEN USING FreeBSD-centric
password files--we have a package that you can drop in for DES passwords
WITH the FreeBSD centric format. Right now when you drop DES in DES
becomes the default, and from that point forward everything is DES,
although it will still read MD5 passwords changing a password will make
it a DES password.
I can see the reasons for having a complete DES oriented system. However I
can also see the reasons for having a progressive oriented system,
defaulting to the best algorithm rather than the worst--while still
handling older algorithms. To make it upwardly scaleable you have to:
1) not hook other programs into the crypt version, simply have them
feed the existing password as the seed when matching passwords, and
2) NOT assume any version when creating a seed (passwd will force '$1$'
currently).
3) allow crypt() to default to the most desired algorithm, then programs
such as 'passwd' can create a common seed and feed it to crypt, getting
back the best encryption algorithm.
I think this should be the default behaviour, unless a 'DES-only' package
or option is installed, which would generally imply you do not want ANY of
the progressive password formats anyway (due to network services and
compatability with other systems).
The reason for this behaviour is rather relevant, in my opinion. If you
ever want to convert an existing DES-based system to FreeBSD you have to
stay completely DES based--you cannot switch to better passwd algorithms
because of the default behaviour of crypt() (explained above).
Furthermore there are systems that currently use DES for one reason or
another which may want to use better algorithms, but they cannot without
doing a massive passwd change as they remove DES password support--just
because the way crypt() defaults it will always use DES not something
better.
What I am trying to target is those people trying to go from DES to
something better. Right now this is not a possibility. There are also
systems that dont care about anything else, and dont want to care about
anything else, this is also fine. Frankly there is already not a middle
line, it is one way or the other.
Perhaps this would be better solved if the behaviour of crypt were
managed through something in /etc, such as the existence of:
/etc/crypt.DES
Which would cause crypt() to default DES (like it does now), and if this
file did not exist crypt() would default to the latest/best algorithm it
knows of.
-Brandon Gillespie
(I'm so heated about this because I have several systems which have DES
passwords installed because they were originally Linux, and have a large
user base. I would rather they use MD5 or SHA-1 passwords, but short of
hacking passwd to force that in the future they will stay DES based).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.960829154946.18074B-100000>