pbreit, I think you should open up a issue also!
Richard On Thu, Jun 7, 2012 at 4:00 PM, pbreit <pbreitenb...@gmail.com> wrote: > 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. >>>> >>>
