For example: https://docs.djangoproject.com/en/dev/topics/auth/#password-upgrading
"When users log in, if their passwords are stored with anything other than the preferred algorithm, Django will automatically upgrade the algorithm to the preferred one. This means that old installs of Django will get automatically more secure as users log in, and it also means that you can switch to new (and better) storage algorithms as they get invented." On Thursday, June 7, 2012 12:58:11 PM UTC-7, 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. >>> >>
