I'm going to try to answer both you and Tom at the same time. One of
the few times I didn't bother checking mail at least once after finishing
on Friday night and I have over 300 waiting for me on Monday morning.
Nick Harring writes:
> Tom Collins wrote:
> > For generating a salt, I think we're fine with the following
> > initialization:
> > srandom (time(NULL)^(getpid()<<15));
Better than what you have, but I suspect that if Larry Wall came up
with the solution I quoted he'd given it a lot of thought and rejected
simpler solutions for valid reasons.
> > I think it would be extremely difficult to predict the salt of a
> > generated password, and even if it was possible, it doesn't really
> > matter.
Not if you store cleartext passwords too, that's for sure.
> > Knowing a password's salt but not the encrypted password
> > doesn't help you to crack it.
If you can get the password file somehow, you get both the salt and
the crypted password. And you're right that if somehow you have only
the salt, or can predict it, it doesn't help you crack the password.
But I am thinking of the case where the password file is (somehow)
stolen and does not have cleartext passwords. If the random seeding
process restricts the range of salt greatly, then a precomputed attack
becomes more feasible. After all, it is the relatively small salt
size and the abiliity of computers of a few years ago to mount
precomputed attacks that led to modern unices replacing the old DES
crypt with an MD5-based one which had much larger salt..
> > If you were trying to guess a randomly generated password,
That's the other problem. If the random password generation in vpopmail
uses the same seed method, the password space may be a lot smaller than we
would like to think.
> > If you knew a process ID range and time range for when the password
> > was generated, you could try thousands, if not millions of seeds to
> > find one that generates the salt. At that point, you could continue
> > the password generating routine to determine what the random password
> > was.
You don't need to compare the salt to see if it's right, you just guess
the initial seed and go through the same process that vpopmail does -
either you get the right password or you don't. If you have an idea of
the time you may find that the current seed generation drastically
limits the seed space even if you have to take random guesses at the PID.
My gut feeling is that the method currently used does reduce the seed
space (but I'm not mathematical enough to prove it).
Remember that rand() is entirely predictable if you know the starting
seed, so no matter how many characters in the randomly-generated password,
the actual entropy is no larger than 32 bits (the range of the initial
seed) and possibly a good deal lower if the seed generation is locked
into a small subset of that. With /dev/urandom you get a good deal
more entropy for password generation and for MD5 salt.
> While I would tend to agree that that might be "good enough", I would
> also say that if its feasible it'd be much better to check for
> /dev/(u)random at compile time and if present then use that.
It's extra coding. :( But I think i's worthwhile.
> I wouldn't bother changing the existing seeding function for rand, as
> long as the only thing its being used for is salt generation.
If I read Tom's reply correctly, it's also used for randomly-generated
> The salt isn't really a route to attacking the password
See above. If somebody can read the password file, the entropy of
the salt is all that makes a precomputed attack infeasible. In some
organizations, it is considered important to guard against that even if
the fact is that if somebody can get the password file you probably have
a lot more to worry about than that. If you use an off-site backup
facility run by another company, how do you know that somebody there
won't go through your backups and get the password files and then send
a mail in one of your user's names that costs you a lot of money?
> All it does is lower the brute force workload by a certain amount,
Brute force is not the only attack. Precomputed attacks can be very
effective if the salt space is small.
> I would think just wrapping the srandom seeding in #ifdef's and adding a
> check in configure would work,
I would add more #ifdefs to replace the call to rand with a read from
/dev/urandom. Using /dev/urandom to seed rand() only gets you 32 bits
of entropy (on most architectures).