Were these suggestions considered or deployed? In light of today's LinkedIn compromise, I am again searching for either a salted password or bcrypt solution.
On Friday, July 31, 2009 12:40:35 PM UTC-7, Jonathan Lundell wrote: > > There are several measures we might take to tighten up default security in > a backwards-compatible way. > > 1. Use IS_STRONG() by default in the welcome application template. > > 2. Add salted hash methods, in particular a) random salt, and b) using the > user's email address as salt (it's not as good as random salt, but it > doesn't have to be appended to the hash, since it's already available). > > 3. Add a meta hash method for migrating hashes. Let a site that's using > currently using some WEAKHASH() (default CRYPT() in particular) to specify > a hash type of MIGRATEHASH(WEAKHASH, STRONGHASH). The rule for this method > is to always use STRONGHASH, with one exception: on login, if STRONGHASH > fails, try WEAKHASH. If WEAKHASH succeeds, then update the user table with > STRONGHASH. > > 4. Given (2) and (3), then by default CRYPT() could be redefined as > MIGRATEHASH(OLDCRYPT, STRONGHASH), for some strong hash. > > 5. Add a defense against blind brute-force attacks by rate-limiting login > attempts, but some method tbd. > > 6. Consider some mechanism that requires a user to choose a new password > (aging, perhaps), so that IS_STRONG can be enforced. > > 7. Encrypt the user table (or at least critical fields in it) with a > secret key, so that if someone gains access to the database, they don't get > access to email addresses or password hashes. This raises the question of > how to keep the secret key secret, but at the very least it can be kept > separate from the database, say in an access-controlled file in the > filesystem. > > 8. Note that (7) introduces the general problem of secret-key management, > which is also an issue for HMACs. Some general solution would be nice. > > 9. Finally, none of this helps against a stolen-password attack. For that, > we ought to be supporting two-factor authentication. I assume that we can > do this already via third-party methods; perhaps we could identify someone > supporting something like the Verisign dongle. >
