Re: Methodology for increasing the number of PBKDF2 iterations

It's time to decide how much to bump the iterations for Django 2.1 -- anyone care to make a proposal? My understanding is that we should revisit the current "bump by 20% each release" guideline in Django's release checklist. Django 2.0 uses 100,000 iterations. On Sunday, February 12, 2017 at

Re: Methodology for increasing the number of PBKDF2 iterations

If anyone is still following this thread... =) I've just updated the Google sheet above with significant changes. I was using the wrong values for PBKDF2-HMAC-SHA256 hash performance. I now have up-to-date hw costs and new evidence in play. Definitely worth having a look at the latest version.

Re: Methodology for increasing the number of PBKDF2 iterations

*IMPORTANT NOTICE:* I've just made an important change to the Google Docs Sheet here: https://docs.google.com/spreadsheets/d/16_KdYAW03sb86-w_AFFnM79IaTWQ7Ugx4T0VMfGteTM/edit?usp=sharing Realizing that most security policies make requirements such as "At least 1 character must be a numeral",

Re: Methodology for increasing the number of PBKDF2 iterations

W dniu poniedziałek, 16 stycznia 2017 18:55:25 UTC+1 użytkownik Martin Koistinen napisał: > > 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. >

Re: Methodology for increasing the number of PBKDF2 iterations

Updated the sheet with more recent GPU pricing. On Thursday, January 19, 2017 at 1:19:57 PM UTC-5, Martin Koistinen wrote: > > All, I've converted my worksheet into a Google Docs Sheet here: > https://docs.google.com/spreadsheets/d/16_KdYAW03sb86-w_AFFnM79IaTWQ7Ugx4T0VMfGteTM/edit?usp=sharing >

Re: Methodology for increasing the number of PBKDF2 iterations

All, I've converted my worksheet into a Google Docs Sheet here: https://docs.google.com/spreadsheets/d/16_KdYAW03sb86-w_AFFnM79IaTWQ7Ugx4T0VMfGteTM/edit?usp=sharing Note that it isn't really editable here. You'll need to make a copy into your own account or download into a local spreadsheet to

Re: Methodology for increasing the number of PBKDF2 iterations

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

Re: Methodology for increasing the number of PBKDF2 iterations

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

Re: Methodology for increasing the number of PBKDF2 iterations

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

Re: Switching the default password hasher to Argon2 (was: Methodology for increasing the number of PBKDF2 iterations)

One issue is that as far as I know, only PBKDF2 is officially approved by the NIST for password hashing. Many security standards explicitly or implicitly (e.g. "strong cryptography") defer to the NIST, and even if

Re: Switching the default password hasher to Argon2 (was: Methodology for increasing the number of PBKDF2 iterations)

Hah, sure, exactly like that! Is it documented? Yes, yes it is. https://docs.djangoproject.com/en/1.10/topics/auth/passwords/#using-argon2-with-django On Monday, 16 January 2017 20:12:23 UTC+11, Florian Apolloner wrote: > > > > On Monday, January 16, 2017 at 3:56:44 AM UTC+1, Josh Smeaton

Re: Switching the default password hasher to Argon2 (was: Methodology for increasing the number of PBKDF2 iterations)

On Monday, January 16, 2017 at 3:56:44 AM UTC+1, Josh Smeaton wrote: > > I think adding argon2_cffi to extra_requires could be a good idea, so that > users can pip install Django[argon2_cffi]. > You mean like https://github.com/django/django/blob/master/setup.py#L53 *scnr* -- You received

Re: Switching the default password hasher to Argon2 (was: Methodology for increasing the number of PBKDF2 iterations)

> That said, it is pretty incredible that beginners can (still) install Django just about anywhere they have Python without compiling anything at all. I think this comment perfectly summarises my initial resistance to forcing this change. I think adding argon2_cffi to extra_requires could be

Switching the default password hasher to Argon2 (was: Methodology for increasing the number of PBKDF2 iterations)

On Thu, Jan 5, 2017 at 10:58 AM, Martin Koistinen wrote: > Slightly off-topic, this presents a really nice case for switching to > Argon2 via argon2_cffi (supported in Django 1.10+). Its super fast (C-lib) > and resistant to GPU/ASIC brute-forcing. So, where as an

Re: Methodology for increasing the number of PBKDF2 iterations

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

Re: Methodology for increasing the number of PBKDF2 iterations

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

Re: Methodology for increasing the number of PBKDF2 iterations

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

Re: Methodology for increasing the number of PBKDF2 iterations

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

Re: Methodology for increasing the number of PBKDF2 iterations

That's a correct assumption -- you won't be able to use pip without OpenSSL. Alex On Mon, Jan 9, 2017 at 7:39 PM, 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

Re: Methodology for increasing the number of PBKDF2 iterations

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

Re: Methodology for increasing the number of PBKDF2 iterations

Slightly off-topic, this presents a really nice case for switching to Argon2 via argon2_cffi (supported in Django 1.10+). Its super fast (C-lib) and resistant to GPU/ASIC brute-forcing. So, where as an attacker's 8-GPU hashing machine would probably have something on the order of 24,000X more

Re: Methodology for increasing the number of PBKDF2 iterations

If anyone is curious about the breakdown of versions, I used the following query: SELECT REGEXP_EXTRACT(details.python, r"^([^\.]+\.[^\.]+\.[^\.]+)") as python_version, COUNT(*) as download_count, FROM TABLE_DATE_RANGE( [the-psf:pypi.downloads], DATE_ADD(CURRENT_TIMESTAMP(), -2,

Re: Methodology for increasing the number of PBKDF2 iterations

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

Re: Methodology for increasing the number of PBKDF2 iterations

Okay, for good measure, here's with 2.7.7. And yeah, looks like almost 4x slower. Python: 2.7.7, Django: 1.10.4 Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification takes, on average, 0.3050s Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification takes, on average,

Re: Methodology for increasing the number of PBKDF2 iterations

Thanks Alex, TIL https://mail.python.org/pipermail/distutils-sig/2016-May/028986.html On 4 January 2017 at 17:42, Alex Gaynor wrote: > Python 2.7.12 will look the same as 3.5.x, they both have the optimized > implementation. Only 2.7.X where X<8 will have the slow

Re: Methodology for increasing the number of PBKDF2 iterations

Python 2.7.12 will look the same as 3.5.x, they both have the optimized implementation. Only 2.7.X where X<8 will have the slow implementation. If someone was motivated, they could look at the PyPI bigquery and see what versions of 2.7 people are using to install django. Alex On Wed, Jan 4,

Re: Methodology for increasing the number of PBKDF2 iterations

FWIW, here are my own results from that benchmark (I ran each 5 times just to account for any other system activity): Python: 2.7.12, Django: 1.10.4 Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification takes, on average, 0.0884s Using cipher: "pbkdf2_sha256" with 100,000

Re: Methodology for increasing the number of PBKDF2 iterations

Here's an interesting tidbit from Alex Gaynor in 2014: https://github.com/django/django/commit/6732566967888f2c12efee1146940c85c0154e60#diff-dd9c116fcefaf3916ace2608656311e0 It's worth noting that, if I'm understanding this correctly, there are two slow versions of pbkdf2 we have to worry about

Re: Methodology for increasing the number of PBKDF2 iterations

Still, this benchmark shows Python 3.5 being 3 times slower than Python 2.7. This is a surprisingly large regression for this time-sensitive function. -- Aymeric. > On 4 Jan 2017, at 02:06, Tim Graham wrote: > > The PBKDF2 speed improvements are in Python 2.7.8 and

Re: Methodology for increasing the number of PBKDF2 iterations

The PBKDF2 speed improvements are in Python 2.7.8 and 3.4+, so you'd need to use Python 2.7.7 or earlier to get the slower version. On Tuesday, January 3, 2017 at 7:56:35 PM UTC-5, Martin Koistinen wrote: > > H, I just tried this using a simple management command to do some > basic

Re: Methodology for increasing the number of PBKDF2 iterations

H, I just tried this using a simple management command to do some basic benchmarking of password hashing. I made this little package Py2/Py3 compatible. You can find it here: https://github.com/mkoistinen/hash_benchmark (Just install it from the repo into an existing project, then add

Re: Methodology for increasing the number of PBKDF2 iterations

H, I just tried this using a simple management command to do some basic benchmarking of password hashing. I made this little package Py2/Py3 compatible. You can find it here: https://github.com/mkoistinen/hash_benchmark (Just install it from the repo into an existing project, then add

Re: Methodology for increasing the number of PBKDF2 iterations

On Tue, Jan 3, 2017 at 1:14 PM, Adam Johnson wrote: > But, to be consistent with Django 1.x going forward, let's define 36,000 >> iterations as "acceptable performance" for a Python2 with Django 1.11 >> install on a typical piece of server hardware today (beginning of 2017). A >>

Re: Methodology for increasing the number of PBKDF2 iterations

> > But, to be consistent with Django 1.x going forward, let's define 36,000 > iterations as "acceptable performance" for a Python2 with Django 1.11 > install on a typical piece of server hardware today (beginning of 2017). A > useful benchmark would be to determine how many iterations would yield

Re: Methodology for increasing the number of PBKDF2 iterations

I think the best practice is to set the iterations as high as you can tolerate without adversely affecting the user experience as they log-in. Iteration numbers as high as 200,000 for SHA-256 or even more are not unheard of these days. Without looking at an application's password expiration

Re: Methodology for increasing the number of PBKDF2 iterations

Now that Python 2 is dropped in Django 2.0 and a faster implementation of pbkdf2 is guaranteed to be available (from what I understand), it's time to reevaluate our strategy for increasing the number of iterations each release. I'm not sure how to evaluate potential performance issues from

Re: Methodology for increasing the number of PBKDF2 iterations

On 22 sept. 2015, at 21:21, Tim Graham wrote: > At this point, I'm inclined to continue with the 20-25% iterations increase > per release methodology we've been using unless someone wants to advocate for > one of the other proposals. I agree. -- Aymeric. -- You

Re: Methodology for increasing the number of PBKDF2 iterations

> On 22 sept. 2015, at 19:22, Christophe Pettus wrote: > > Given that it is a unidirectional hash, I'm not sure how they *would* be > rehashed. If you have password hashed at 15 000 rounds and want 20 000, you do 5 000 rounds on the current hash. (I don’t know if Django

Re: Methodology for increasing the number of PBKDF2 iterations

Right -- the performance is only slightly worse during an upgrade than during other actions. I found the conversation I was thinking about. It's in the private security tracker (the patch to upgrade the iterations count was developed there), so I'll copy/paste the relevant bits here. The patch

Re: Methodology for increasing the number of PBKDF2 iterations

Sure, but such a problem has nothing to do with password upgrades, it can already be triggered by registration, or even just logging in without a password upgrade. Alex On Tue, Sep 22, 2015 at 2:43 PM, Tim Graham wrote: > Sorry, I explained poorly. We do upgrade passwords

Re: Methodology for increasing the number of PBKDF2 iterations

Sorry, I explained poorly. We do upgrade passwords when the iteration count is increased https://docs.djangoproject.com/en/1.8/topics/auth/passwords/#password-upgrading If we increase the iterations to , when a user logs in, we have to hash to check the password against the current hash plus

Re: Methodology for increasing the number of PBKDF2 iterations

On Sep 22, 2015, at 10:27 AM, Tim Graham wrote: > We have access to the plain text password when the user logs in. Right, so we could *in theory* upgrade the user's password then if we wished (not clear if we want to). Even so, I don't think that would be a DDoS-attack

Re: Methodology for increasing the number of PBKDF2 iterations

We have access to the plain text password when the user logs in. On Tuesday, September 22, 2015 at 1:23:01 PM UTC-4, Xof wrote: > > > On Sep 22, 2015, at 10:18 AM, Tim Graham > wrote: > > > As I understand it, the problem with increasing the number of iterations > on the

Re: Methodology for increasing the number of PBKDF2 iterations

On Sep 22, 2015, at 10:18 AM, Tim Graham wrote: > As I understand it, the problem with increasing the number of iterations on > the slower hasher is that upgrading Django could effectively result in a DDoS > attack after you upgrade Django as users passwords are

Re: Methodology for increasing the number of PBKDF2 iterations

As I understand it, the problem with increasing the number of iterations on the slower hasher is that upgrading Django could effectively result in a DDoS attack after you upgrade Django as users passwords are upgraded. Some benchmarking suggests that the new algorithm results in a 3x speed up

Re: Methodology for increasing the number of PBKDF2 iterations

Is the concern that 100,000 iterations is too slow on python < 2.7.8 but is acceptable on versions after that? If so, then we wouldn't be breaking < 2.7.8, we'd just be reducing the performance profile, right? We could call out such things in the release notes. On Tuesday, 22 September 2015

Re: Methodology for increasing the number of PBKDF2 iterations

On September 21, 2015 at 10:55:57 AM, Collin Anderson (cmawebs...@gmail.com) wrote: > Is there an external library for Python < 2.7.8? I know we don't officially > support the system version of python in RHEL/CentOS and Ubuntu, but I bet > we could get away with requiring a dependency for those

Re: Methodology for increasing the number of PBKDF2 iterations

On September 20, 2015 at 7:26:09 PM, Alex Gaynor (alex.gay...@gmail.com) wrote: > > Unfortunately 24k iterations is behind where we'd want to be > (~100k iterations, or a factor of 4, last I checked). If I remember, a key thing was we wanted the PBKDF2 iterations to be much higher than they were

Re: Methodology for increasing the number of PBKDF2 iterations

Unfortunately here is where we hit an asymmetry: single threaded performance of PBKDF2 _as realized in our pure Python implementation_ indeed does not improve by 25% every 8 months. Unfortunately 24k iterations is behind where we'd want to be (~100k iterations, or a factor of 4, last I checked).

Methodology for increasing the number of PBKDF2 iterations

The latest guidance on increasing the number of PBKDF2 iterations for each release of Django was written by Alex in July 2014: For each release... "Increase the default PBKDF2 iterations in django.contrib.auth.hashers.PBKDF2PasswordHasher by about 20% (pick a round number)." He noted in that