From owner-freebsd-security Thu Jul 8 2:14:38 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id C7A9F14DB0 for ; Thu, 8 Jul 1999 02:14:32 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id LAA16754; Thu, 8 Jul 1999 11:14:31 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id LAA49653; Thu, 8 Jul 1999 11:14:30 +0200 (MET DST) Date: Thu, 8 Jul 1999 11:14:30 +0200 From: Eivind Eklund To: Kris Kennaway Cc: Peter Wemm , security@freebsd.org Subject: Re: Improved libcrypt ready for testing Message-ID: <19990708111429.E46370@bitbox.follo.net> References: <19990707172115.D44021@bitbox.follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: ; from Kris Kennaway on Thu, Jul 08, 1999 at 09:35:29AM +0930 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Jul 08, 1999 at 09:35:29AM +0930, Kris Kennaway wrote: > On Wed, 7 Jul 1999, Eivind Eklund wrote: > > > If we want to support protocol-embedded authentication data properly, > > we need at least the ability to store several different types of > > hashes for each user in the password file, and the ability to store > > clear-text passwords. > > Storing cleartext passwords is easy enough - just define a minimal hash > function which base64's the plaintext, and null salt function. > > I'll have to think about how multiple password hashes could best be > implemented - any suggestions? For the master password file itself, I guess we could just put several hashes in the password field, separated by commas (which I don't think are allowed in any of the present hashes). I don't know how to fit multiple hashes into the databases; I've not looked too carefully at these. > > > We should also, IMO, be switching our default password file format to > > SRP or similar - something that allow challenges against it without > > being the cleartext. > > I have the SRP reference implementation working at home - it requires changes > to clients, though. Does it require changes to clients in order to be used as a normal password hash, not to do challenges against? I can't remember anything about it that would force that? Just using it as a hash format in our password file would give the userbase time to transition, and would poise us perfectly for further use. > This would probably best be integrated with a PAM module talking to > the crypt backend (such a beast exists already, but I haven't tested > it). It would be very, very nice if we were able to support it :) Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message