A few minor points. On Wed, May 20, 2009 at 6:00 PM, Arthur Corliss <[email protected]> wrote: > On Wed, 20 May 2009, Bill Ward wrote: > >> 2. Make sure to have a salt value, as it prevents the use of rainbow >>> >>> tables to get a password. So you have the hash and a known salt kept >>> separately (the salt is plaintext), and when you check the password >>> you check: sha256(passphrase + salt) == sha256(passphrase_entered + >>> salt) >> >> I'm not doing that, but that wouldn't be hard to add. I didn't think that >> a >> salt was necessary with a one-way hash. > > Salts are a way of combating the use of rainbow tables, which is a database > of precomputed values within certain bounds. Makes brute force attacks > virtually painless, becuase now it's just a lookup. But don't add a static > salt, that's almost as pointless as not using one at all. If you're going > to use salts make sure you generate a new one every time, preferrably > pulling a few bytes from /dev/u?random or similar. 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.
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) > > If you're really paranoid you'll also do key strengthening, similar to what > most system authentication does. Hash with a salt, then hash the result > with the salt, repeat a few thousand times. > > --Arthur Corliss > Live Free or Die >
