From owner-freebsd-stable Wed Aug 9 13:22:52 2000 Delivered-To: freebsd-stable@freebsd.org Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id BB03037B6D1; Wed, 9 Aug 2000 13:22:41 -0700 (PDT) (envelope-from green@FreeBSD.org) Date: Wed, 9 Aug 2000 15:59:02 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: Pete Carah Cc: current@FreeBSD.org, stable@FreeBSD.org Subject: Re: crypt(3) problems In-Reply-To: <200008091855.LAA02796@ns.altadena.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 9 Aug 2000, Pete Carah wrote: > > We should switch to using just libdescrypt and being allowed to switch > > crypt formats easily between md5 and des. My proposed solution using > > login.conf is at http://people.FreeBSD.org/~green/crypt_switching.patch, > > and it's going to be put into production usage relatively soon (that is, > > whether or not it's actually in FreeBSD). > > As long as things get switched around so that the format decision is > external to libdescrypt and the existing password, so we can change an existing > des passwd to md5. However, in our case, apache still needs to > generate des but *all* other uses want md5. The link choice is the > easiest way to select this, with environment next. Config files won't > really work since they can't anticipate all uses. Well, first of all assume that by default DES-based scheme is what crypt() uses. > The full-blown pam implementations do it with pam parameters; login.conf > is fine but won't work for "third-party" situations like I was commenting > on (i.e. apache needs to accept and generate des but most other need > md5, etc etc)... Perhaps an environment variable? PAM still needs support from the crypt() library. There's not going to be a way to do it without a proper interface to the crypt library :-/ Right now there is int crypt_set_format(const char *format); This wouldn't be thread-safe to change formats, but crypt() isn't thread safe in the slightest bit anyway, by design. > libdescrypt is close since it will accept either; a fixed choice for > what it generates, external to *any* application code (e.g. environment > vars (easiest) or (if possible) config files that are somehow *completely* > universal (I don't see how to do this without application mods unless the > library can transparently get at argv[0] independently of what the app does > like ++argv, etc)) would be nice. You really cannot do this properly. It's best just to do what it takes to get the right format on a given platform. On FreeBSD now, that's use libdescrypt and crypt() with a normal salt, or to get MD5 use a salt with the "$1$" format. On FreeBSD with the changes I have, you call e.g. crypt_set_format("md5") and then crypt() with a generic salt. > -- Pete -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message