Date: Wed, 22 Apr 1998 00:54:10 +0200 (MET DST) From: Janos Mohacsi <mohacsi@bagira.fsz.bme.hu> To: Jeff Aitken <jaitken@dimension.net> Cc: freebsd-security@FreeBSD.ORG Subject: Re: md5, des, et al. Message-ID: <Pine.SUN.3.96.980422004125.9694B-100000@bagira.fsz.bme.hu> In-Reply-To: <199804211812.OAA27421@gizmo.dimension.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 21 Apr 1998, Jeff Aitken wrote:
> Date: Tue, 21 Apr 1998 14:12:49 -0400 (EDT)
> From: Jeff Aitken <jaitken@dimension.net>
> To: freebsd-security@FreeBSD.ORG
> Subject: md5, des, et al.
>
> A recent poster (sorry, I deleted the message, so I don't remember
> who) said something about using dlopen() and friends (we'll assume
> for argument's sake that that will work flawlessly).
>
> However, doesn't any solution involving shared {libraries,object code}
> merely solve half of the problem? Suppose you have md5.so, des.so,
> blowfish.so, and foobar.so. Obviously, you can now decrypt
> passwords encrypted with DES, MD5, etc. However, when a user
> changes his or her password, which scheme is used to generate the
> new password?
>
> Situation 1: Administrator A set up FreeBSD to use MD5 because it's
> he default. He later wants to be able to share passwords with
> other UNIX boxes, so he needs to convert all passwords to DES.
> Thus, he needs to read MD5 but write DES. (ala Ultrix's UPGRADE
> security mode). This scenario equates to "read any, write one".
>
> Situation 2: Administrator B sets up a FreeBSD NIS master. over
> time, his userbase expands to include users in multiple countries.
> Some of those countries forbid the use of "strong" encryption.
> Administrator B would like to use MD5 for USA users, but some simple
> obfuscation for users in one of those other countries. Thus, the
> reading/writing mechanism must be able to write different formats
> to the same file. This scenario equates to "read any, write any".
>
> Granted, the second situation might be a little more farfetched, but
> it's certainly not outside the realm of possibility. Seems to me
> that passwd.conf is about the only way to make this work. Or am I
> missing something obvious?
I agree with some point of above. Both scenario should be supported if it
is possible. But I don't think that should be invented a new password
config file as in OpenBSD. We already have a general config file:
/etc/login.conf. This better than a new one, because the infrastructure
for handling it already exist. Two new field should be added in
/etc/login.conf : localcipher, ypcipher.
(this can allow read any, write any semantics)
localcipher - for storing to a local password stuffs.
ypcipher - for storing to YP (for compatibility).
(kerberos password handled completely different.)
And should be integrated the new FreeSEC??? (by the way where it is
available?) for the blowfish encryption too.
Is anybody to add it into the current lib tree?
Sincerely,
Janos Mohacsi
P.S.: I have posted a similar message a day before but it did not get
thru. If yes, sorry for it.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.96.980422004125.9694B-100000>