Ummm, some quick digging later and the situation is worse than I thought.
Not only does vpopmail use rand(), it initializes srand with a variant
of time(NULL) ^ getpid(). time(NULL) ^ getpid() has long been known to
not be a good way of seeding the random number generator. I think the
variant vpopmail uses is actually likely to make it quite a bit worse.
If nothing else, I'd suggest replacing the rand() % time(NULL) ^ getpid()
with time(NULL) ^ (getpid() + (getpid() << 15)) as recommended by Larry
Wall. At best, I would attempt to determine if /dev/urandom exists
(either at configuration time or at run time) and use that if possible,
reverting to the Wall function if /dev/urandom is not available.
For generating a salt, I think we're fine with the following initialization:
srandom (time(NULL)^(getpid()<<15));
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. Knowing a password's salt but not the encrypted password doesn't help you to crack it. Once you have the encrypted password, you get the salt.
If you were trying to guess a randomly generated password, it might be possible to use the salt to determine the starting seed to srand and then determine the password used. 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.
-- Tom Collins - [EMAIL PROTECTED] Note: The Tom Logic offices will be closed October 23 to November 18. QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/ Info on the Sniffter hand-held Network Tester: http://sniffter.com/
