From owner-freebsd-security Tue Apr 21 11:13:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA03228 for freebsd-security-outgoing; Tue, 21 Apr 1998 11:13:40 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gizmo.dimension.net (gizmo.dimension.net [209.12.7.20]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA03172 for ; Tue, 21 Apr 1998 18:13:26 GMT (envelope-from jaitken@dimension.net) Received: (from jaitken@localhost) by gizmo.dimension.net (8.8.5/8.8.7) id OAA27421 for freebsd-security@freebsd.org; Tue, 21 Apr 1998 14:12:51 -0400 (EDT) From: Jeff Aitken Message-Id: <199804211812.OAA27421@gizmo.dimension.net> Subject: md5, des, et al. X-ELM-OSV: (Our standard violations) no-mime=1; no-hdr-encoding=1 To: freebsd-security@FreeBSD.ORG Date: Tue, 21 Apr 1998 14:12:49 -0400 (EDT) Reply-to: jaitken@dimension.net X-Mailer: ELM [version 2.4ME+ PL26 (25)] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk 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? -- Jeff Aitken jaitken@dimension.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message