Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 7 Jul 1999 17:21:15 +0200
From:      Eivind Eklund <eivind@FreeBSD.ORG>
To:        Peter Wemm <peter@netplex.com.au>
Cc:        Kris Kennaway <kkennawa@physics.adelaide.edu.au>, security@FreeBSD.ORG
Subject:   Re: Improved libcrypt ready for testing
Message-ID:  <19990707172115.D44021@bitbox.follo.net>
In-Reply-To: <19990706175814.3A9CE78@overcee.netplex.com.au>; from Peter Wemm on Wed, Jul 07, 1999 at 01:58:14AM %2B0800
References:  <Pine.OSF.4.10.9907062308350.13993-100000@bragg> <19990706175814.3A9CE78@overcee.netplex.com.au>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jul 07, 1999 at 01:58:14AM +0800, Peter Wemm wrote:
> Kris Kennaway wrote:
> > On Tue, 6 Jul 1999, Peter Wemm wrote:
> > 
> > > I'd strongly suggest encoding the number of rounds as well, ie:
> > > $token$salt$rounds$password
> > 
> > For the two algorithms which currently support variable rounds, it's
> > already encoded into the password:
> > 
> > $Blowfish$xy$<salt><password> following the OpenBSD format (xy = log2 rounds)
>     ,
> > and
> > 
> > _<rounds><salt><password> for New-DES. (<rounds> encoded as a base-64 binary
> > value).
> 
> Say... you wouldn't like to impliment an NT-style password hash, would you?
> *NOT* the LAN-Manager (LAN-damager?) hash with the 2 chunks of 7 characters
> weak method that gets decoded in what seems like seconds according to
> bugtraq.  The NT hash is 128 character etc.  It's also unicode and not case
> sensitive, but that shouldn't be a problem to implement.
> 
> The reason I ask is that there are a number of protocols that have this
> embedded in it, including PPP's MS-CHAP and SMB.

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.

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.

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?19990707172115.D44021>