I'm not sure the DoS concern is really something that can be addressed here. Regardless of the number of iterations we choose, POSTing to the login form will always be a target, unless it's appropriately protected (i.e., with some combination of rate limiting, recaptcha, and/or something at the network level). A run-of-the-mill cloud server that doesn't limit access to the Python app in some way is simply never going to be a match for a malicious person with a laptop, let alone a more sophisticated attack.
I created a tox.ini <https://github.com/tobiasmcnulty/hash_benchmark-ubuntu-12.04/blob/master/tox.ini> to run Martin's benchmark with multiple Django & Python versions. A couple notes: - I ran this several times on Circle CI using Ubuntu 12.04 <https://circleci.com/gh/tobiasmcnulty/hash_benchmark-ubuntu-12.04/13> with Python 2.7.7, 3.3.3, 3.4.3, and 3.5.0, and Ubuntu 14.04 <https://circleci.com/gh/tobiasmcnulty/hash_benchmark-ubuntu-14.04/1> with 2.7.12, 3.3.6, 3.4.4, and 3.5.2. To view the results, expand the "tox" section under the "Test" header. - All results are what one would expect: Python 2.7.7 and Python 3.3.x are ~3-4x slower than Python 2.7.8+ and Python 3.4+, and there are no inexplicably slow outliers, like the official Python 3.5.2 installer for OS X. My local results are as follows: - Ubuntu 16.04 w/a Core i5 @ 3.50GHz: - 62-65ms for 100,000 iterations - 100-106ms for 165,000 iterations - Mac OS 10.12, Core i5 @ 2.7GHz: - 117-120ms for 100,000 iterations - 195-203ms for 165,000 iterations I really don't know how we can pick a number that'll work for everyone, but I'm all for setting it high and allowing people to decrease the number of iterations or, better yet, switch to the hasher that the docs recommend everyone use anyway <https://docs.djangoproject.com/en/1.10/topics/auth/passwords/#using-argon2-with-django> (Argon2). If we define 100-120ms as acceptable performance, 100k would seem reasonable based on the results above and posted elsewhere in this thread. Martin, FWIW, I can confirm that the Python 3.5.2 installer from python.org demonstrates the same 3x slower behavior on my Mac that you saw. The Python 3.5.2 I installed from Homebrew does not, nor does the official python.org installer for Python 3.6. Based on the absence of any similar outliers in the above tests, however, I still think the conclusion here should be to fix the underlying Python build (if it's really creating a performance issue for you or anyone else), not hold back Django from bumping its default number of PBKDF2 iterations. Dropping Python 2.7 support still means we lose a large swath of definitely-slow PBKDF2 implementations: 24.4% of installs where the Python version was known were using 2.7.5 or 2.7.6 in the chart Alex posted. The point about switching Django's default to Argon2 is an intriguing one. In the event there are still a bunch of slow PBKDF2 implementations out there with Python 3.5+, one benefit of dramatically increasing PBKDF2 iterations is that it might push more people to Argon2. :-D On a more serious note, I'll reply separately to that thread to save this one for the original topic. Tobias On Wed, Jan 11, 2017 at 10:39 AM, Tim Graham <timogra...@gmail.com> wrote: > I agree. The question in my mind is how to pick an appropriate number of > iterations that we don't risk causing a DoS on (at least most) existing > sites due to increased CPU usage. Or at least, can we offer some > suggestions about how to tell if your site receives sufficient traffic that > you might be impacted? Did anyone notice increased CPU usage in past > upgrades? > > On Tuesday, January 10, 2017 at 1:27:19 PM UTC-5, Tobias McNulty wrote: >> >> IMO this doesn't change the argument that it would be best to default to >> the higher number of iterations (i.e., 100k or higher, given some time as >> passed since 2013), while noting in the documentation that individual >> projects have the ability to reduce it if need be (though perhaps >> recommending that they try first to find a faster Python). Other thoughts? >> >> On Mon, Jan 9, 2017 at 10:44 PM, Martin Koistinen <mkois...@gmail.com> >> wrote: >> >>> The Python3.5 on my system was installed by the official Python >>> installer, and is almost 3X slower than the Apple-built 2.7 install. I use >>> pip all day long. >>> >>> True, my MacBook is not a server, but it still serves to demonstrate the >>> point that it is not a reasonable assumption that all 3.5 installs use >>> OpenSSL libraries. >>> >>> On Monday, January 9, 2017 at 7:39:18 PM UTC-5, Tim Graham wrote: >>>> >>>> About "we cannot just assume that all Python 3 installs have a "fast" >>>> PBKDF2 implementation" -- I'd expect very few if any Django users to be >>>> compiling their own Python and doing so without OpenSSL. I'm guessing that >>>> any operating system Python will have the OpenSSL bindings. Or is that a >>>> bad assumption? >>>> >>>> On Wednesday, January 4, 2017 at 2:13:09 PM UTC-5, Martin Koistinen >>>> wrote: >>>>> >>>>> I think this is a pretty solid guess. Bear in mind this was a direct >>>>> install from Python.org. >>>>> >>>>> The important thing here is, this demonstrates that we cannot just >>>>> assume that all Python 3 installs have a "fast" PBKDF2 implementation =/ >>>>> >>>>> On Wednesday, January 4, 2017 at 11:33:17 AM UTC-5, Tobias McNulty >>>>> wrote: >>>>> >>>>>> ... >>>>>> >>>>> Martin, is it possible your version of Python 3 is not linked against >>>>>> OpenSSL and hence is missing the fast version of pbkdf2_hmac? I haven't >>>>>> had >>>>>> a chance to try your benchmark yet, but in a quick test I don't see any >>>>>> difference between Python 3.5.2 and Python 2.7.12 on a Mac. >>>>>> >>>>>> Tobias >>>>>> >>>>> >>>>> >>>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django developers (Contributions to Django itself)" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to django-develop...@googlegroups.com. >>> To post to this group, send email to django-d...@googlegroups.com. >>> Visit this group at https://groups.google.com/group/django-developers. >>> To view this discussion on the web visit https://groups.google.com/d/ms >>> gid/django-developers/9261dcdc-f3b2-458c-a6e1-bde49642c56b%4 >>> 0googlegroups.com >>> <https://groups.google.com/d/msgid/django-developers/9261dcdc-f3b2-458c-a6e1-bde49642c56b%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> >> >> *Tobias McNulty*Chief Executive Officer >> >> tob...@caktusgroup.com >> www.caktusgroup.com >> > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit https://groups.google.com/d/ms > gid/django-developers/34fc63bf-9eff-4ecb-a931-3f25d69faddf% > 40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/34fc63bf-9eff-4ecb-a931-3f25d69faddf%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- *Tobias McNulty*Chief Executive Officer tob...@caktusgroup.com www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMGFDKS_DP2KL3wc9n-qwDWp13t-FVt7%2BFOWwpU4xvOzn3XrFw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
