On Wed, May 20, 2009 at 6:13 PM, Arthur Corliss <corl...@digitalmages.com> wrote: > 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. That's a pretty valid point. If it's a simple auth system as I understand it, though, then the users don't have different permissions, so there's really no point in cracking *all* of the passwords if you can download all the data with one.
Still, good point. Thanks for that :-) > >> 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. Indeed, I was just clarifying for the benefit of others reading this message. > > --Arthur Corliss > Live Free or Die >
