Paul L. Allen wrote:
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:
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'd totally agree here.
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.
Storing cleartext passwords is generally horrible security, so this and
that don't really relate to each other. Yes, I know why people do it,
and I do it myself, but I'm not going to kid myself into thinking that
a better salting scheme is going to help any when I keep clear
passwords around.
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..
This is true, and the same precomputed attacks become much more
feasible (as you correctly point out) when the salt space is
dramatically reduced.
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.
I hadn't checked this, but I'm guessing you're right, and this is a
hugely serious problem.
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 whole heartedly agree. I've been poking around with #ifdef'ing around
the seeding of srandom, however I think your later suggestion of just
replacing rand() with reads from /dev/urandom is the Right Way.
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.
Precomputed attacks are brute force, not that it really matters.
Precomputation just reduces the time frame required to run said brute
force attack. If you're guessing at each element, without any feedback
or algorithm other than trying a list of sequential possibilities,
you're brute forcing.
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).
This is the Right Thing imho. It might be easier though to move the
srandom()/random() and new reads from /dev/urandom into a function of
its own, rather than replacing them whereever they're sprinkled through
the code. I realize that's even more work, but its probably more
maintainable down the road.
Cheers,
Nick Harring
Webley Systems
|
