Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 24 Aug 2000 02:57:39 -0700
From:      D M P <dmp@aracnet.com>
To:        "Andresen,Jason R." <jandrese@mitre.org>
Cc:        Chris Fedde <chris@fedde.littleton.co.us>, freebsd-questions@FreeBSD.ORG
Subject:   Re: More questions about passwords [Was: Re: Encrypting a password for  insertion using chpass(1)?]
Message-ID:  <39A4F193.9BE6005E@aracnet.com>
References:  <200008210537.e7L5bNj25784@fedde.littleton.co.us> <39A36B63.7A5292F9@aracnet.com> <39A3CA70.7F871682@mitre.org>

next in thread | previous in thread | raw e-mail | index | archive | help
"Andresen,Jason R." wrote:
> D M P wrote:
> > Assuming that I am right, logic follows that if I generated a eight
> > random characters to use instead, that it would still work, and the
> > cleartext wouldn't be seen in the cypher.  My question is, how do I
> > input those characters?  Is that the salt I pass to perl's crypt()?
> > Can it be any 64-bit value, or does it have to be comprised of the
> > 64 characters mentioned in crypt(3)?
> >
> 
> Yes, those characters are the salt, and they can be anything you want
> them to be.

Ahh... good.  I'm not very clear on the size of the salt value though.
In perl, how many bits does the salt value have to be?  Above I just
assumed it was 64-bits, based on the password file having eight
characters of salt, but crypt(3) says those characters are just 6
bits long, and my perl book says its crypt() uses a salt of just 2
characters.

> By the way, one thing that is important is to get a truely random salt
> value, since pseudorandom salt values are easier to crack.  This is not
> easy on a computer, rand() and even random() are not up to the task, and
> the Camel book's suggestion is terrible (they use the first few bytes of
> ps output piped to gzip, which is always the gzip magic number!).
> Generally people try something like two random bytes in the current
> system time munged with ps output compressed with gzip.

Anyone know where I can get a geiger counter and some Cesium-137? ;)

I was thinking of something less complicated.  Get the password, crypt
it with itself as the salt, then take the part of the result after the
third $ and it as the salt in a second crypt to produce the actual
string to stick in the password file.

Not random by a long shot, but in this particular case, the extra
work in gather random data is something of an exercise in futility.

As far as truly random salts go, a few lines of perl code could
retrieve an arbitrary number of bits from Hotbits...

$nbytes = 8	#Number of bytes to get, 2048 max.
$socket = IO::Socket::INET->new(www.fourmilab.ch:80);
print $socket "GET /cgi-bin/uncgi/Hotbits?nbytes=", "$nbytes", "&fmt=bin\n";
$saltval = <$socket>

But I'm not sure what John Walker (the creator of Hotbits) would
think if this went into use.

-- 
"Human beings, who are almost unique in having the ability to
 learn from the experience of others, are also remarkable for
 their apparent disinclination to do so."     - Douglas Adams
dmp@{aracnet|coffeylabs).com


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39A4F193.9BE6005E>