Tim, I've sent you a model I've assembled recently for your review. I'll work towards making it more user-friendly (I.e., NOT in Apple Numbers format) and share it here for the whole community.
But for here and now, I would at the very least assume that the cost of a brute-force attack on password hashes falls over time inversely proportional to Moore's Law. Its a naive approach, but is a fairly reasonable one. So, to compensate, we should be doubling the number of iterations every 18-24 months, or perhaps at a minimum, raise them by sqrt(2) annually ~= +40% each year. +40%/year assumes that the starting point of 100,000 is OK for Q1 2017 (this will not be true for every project) and it assumes that Moore's Law is evenly "applied" over time (its not). On Wednesday, January 18, 2017 at 10:25:46 AM UTC-5, Tim Graham wrote: > > I increased the iterations to 100,000 on master (targeting Django 2.0). It > would be nice to determine a guideline for how to determine future > increases. > > On Monday, January 16, 2017 at 12:55:25 PM UTC-5, Martin Koistinen wrote: >> >> Tobias, >> >> Thanks for the comprehensive benchmarking and summary of the situation! I >> agree on all points, but I'd like to add, that we should err on the side of >> high iterations for the simple fact that most developers would sooner >> accept the risk of a DoS long before the risk of compromised user accounts. >> >> Also, if a developer is experienced/motivated enough to *lower* the hash >> iterations, s/he'll be more likely to also be experienced/motivated enough >> to put other controls in place to compensate. >> >> >> Best, >> - Martin >> >> On Sunday, January 15, 2017 at 5:45:02 PM UTC-5, Tobias McNulty wrote: >>> >>> 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 >>> >>> -- >>> >>> >>> *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/451d045d-27a8-4353-b83b-28f1cdadbc50%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
