Date: Thu, 8 Jul 1999 11:14:30 +0200 From: Eivind Eklund <eivind@freebsd.org> To: Kris Kennaway <kkennawa@physics.adelaide.edu.au> Cc: Peter Wemm <peter@netplex.com.au>, security@freebsd.org Subject: Re: Improved libcrypt ready for testing Message-ID: <19990708111429.E46370@bitbox.follo.net> In-Reply-To: <Pine.OSF.4.10.9907080928090.20360-100000@bragg>; from Kris Kennaway on Thu, Jul 08, 1999 at 09:35:29AM %2B0930 References: <19990707172115.D44021@bitbox.follo.net> <Pine.OSF.4.10.9907080928090.20360-100000@bragg>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990708111429.E46370>