Password hashing parameters selection methodology description

[Martin Koistinen]

Django has a very nice implementation for hashing passwords using PBKDF2 and a number of iterations to increase the work-load. Thanks!

I know this is very customizable and I know how to do this. This post is not about "how".

What I would like to know is the methodology and "inputs" into deciding the number of iterations. For a quick summary, these iterations change with every recent iteration of Django as follows:

• Django 1.10: uses 30000 iterations
  
• Django 1.9: 24000
  
• Django 1.8: 20000
  
• Django 1.7: 15000
  
• ...
  

Clearly these are increased to offset increases in computational power of the typical server, etc. But is there anything more methodical to this than just "hey, let's add some iterations to the default password hasher" for each release?

Ideally, someone could make plain the methodology used, the inputs/assumptions and the desired strength achieved (I.e., how many days of brute-forcing does a hashed password withstand on some assumed set of hardware). I suspect that the Django project is not inventing the methodology but rather is using a reference to a study somewhere.

Anyone have this handy somewhere?

Many thanks!

[Tim Graham]

From the "new stable branch" tasks [0]:

Increase the default PBKDF2 iterations in django.contrib.auth.hashers.PBKDF2PasswordHasher by about 20% (pick a round number). Run the tests, and update the 3 failing hasher tests with the new values. Make sure this gets noted in the release notes (see the 1.8 release notes for an example).

To see the discussion about the reasoning, I'd suggest to search the archives of the django-developers mailing list and/or the Django ticket tracker -- that's what I'd do to answer your question.

This is the last topic I remember about it:
https://groups.google.com/d/topic/django-developers/Qab-hRG-SKs/discussion

[0] https://docs.djangoproject.com/en/dev/internals/howto-release-django/#new-stable-branch-tasks