https://groups.google.com/d/msg/web2py/WEiNGgDya58/ljDoE23gI8gJ
On Thursday, June 7, 2012 3:58:11 PM UTC-4, pbreit wrote: > > Bumping since another password compromise came out today (last.fm). > > I would like to at least salt my passwords. Also would be nice to have a > bcrypt option. Finally, would be nice to have an easy way to migrate an > existing set of users to new password scheme as they log in (or I've also > seen suggested encrypting current encrypted strings and then checking both > ways in the future). > > > > On Wednesday, June 6, 2012 9:35:41 AM UTC-7, pbreit wrote: >> >> 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. >>> >>
