On Wed, 20 May 2009, Jonathan Yu wrote:
Not totally pointless, of course, because it would still require
regenerating a rainbow table versus downloading one of them already
available. On the other hand, depending how popular your application
gets, this can be dangerous -- take for example Microsoft's Lan
Manager Hash algorithm, LMHash. Even though it is a specialized
algorithm, it became popular enough to make it feasible/useful to
create and distribute rainbow tables for. So your point is valid in
that case, and it never hurts security nor is it a big deal on
performance.
I would suggest that the benefit of a static salt is marginal in best since
many of these hash algorithms aren't exactly computationally intensive on
today's hardware. If you have a guy trying to crack passwords from a shadow
file he's only got to generate one table for all of them, versus a table per
account. It's an order of magnitudes more difficult in that regard,
especially if you expand the scope to all users of an application every
where.
And /dev/random can be slow, so urandom is a better suggestion, or
even better, using /dev/random to seed a random number generator
algorithm like the Mersenne Twister (which is essentially what
/dev/urandom does)
Which was why included urandom as a suggestion.
--Arthur Corliss
Live Free or Die
