On Tuesday, October 28, 2003, at 02:42 AM, Paul L. Allen wrote: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. I wouldn't bother changing the existing seeding function for rand, as long as the only thing its being used for is salt generation. The salt isn't really a route to attacking the password since you don't need it to brute force the password if you can get the encrypted password string, and having it doesn't allow you to go backwards from the string. All it does is lower the brute force workload by a certain amount, which I can't remember and can't quickly find on google.
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/
I would think just wrapping the srandom seeding in #ifdef's and adding a check in configure would work, and I'm working up a patch to do the first bit, though I know zero about configure/autoconf and thus can't help there. I'll submit via sourceforge once I get it working and non-ugly.
Cheers,
Nick Harring
Webley Systems
