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 passwords. > 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). -- Paul Allen Softflare Support