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

[Tobias McNulty]

On Thu, Jan 5, 2017 at 10:58 AM, Martin Koistinen <mkois...@gmail.com> 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 attacker's 8-GPU hashing machine would probably have something on the order of 24,000X more hashing capability for SHA256 than a typical Django server, I estimate that the same hardware (8 GPUs) would only have about 20-30X more hashing capability than a typical server. (Note, the anecdotal evidence across the internet supporting this is pretty thin).

This is an interesting point. Argon2 is recommended over PBKDF2 by OWASP and even Django itself. From what I understand, the only reason it's *not* the default now is the 3rd party dependency, which does require a C compiler and the libffi library to build, if a wheel isn't available for your OS. In a minimal Python 3.5-alpine Docker image, I needed the following packages before I could `pip install argon2_cffi` (which themselves had a collective ~12 additional dependencies):

• gcc
• musl-dev (libc headers)
• libffi
• libffi-dev

Could anyone familiar with the draft DEP 7: Dependency Policy and/or the addition of the Argon2 hasher comment on the suitability of argon2_cffi (or not) for consideration under DEP 7? I think it meets most if not all of the "maturity" guidelines in the policy, with the one exception being that it presents an interesting test case for the footnote on the "dependencies that require C extensions are probably not acceptable" statement. There are wheels available for argon2_cffi on a large number of platforms, but I still had to compile it manually on Alpine Linux (a popular OS for minimal Docker images) and for Python 3.6 on my Mac (there is a wheel available when using Python 3.5 on a Mac).

I have trouble imagining that there are many production Django apps out there that don't compile *something* in their requirements file (e.g., psycopg2 or Pillow), in which case argon2_cffi essentially requires no extra lift. That said, it is pretty incredible that beginners can (still) install Django just about anywhere they have Python without compiling anything at all.

I wonder if there's an alternative to forcibly requiring it, where most users would eventually do so for production use, but had greater flexibility when running locally? Only the security-minded will go through the trouble of changing the default password hasher currently, so ideally users would get a stronger nudge than they do now when it comes time to deploy to production. Making a switch here also has the added benefit of circumventing some of the concerns around increasing PBKDF2 iterations over time.

Tobias

--

Tobias McNulty
Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

[Josh Smeaton]

> 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 a good idea, so that users can pip install Django[argon2_cffi]. We could then have a check that tries to import it, and warns users if the argon2 hasher isn't in the list of hashing algorithms. Alternatively, we could have the argon2 in the hasher list of the default template, and do a warnings.warn() if the import of the dependency fails.

I'm all for making it easier to use argon2, but not at the expense of harming the experience for devs newer to Django.

[Florian Apolloner]

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* 

[Josh Smeaton]

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

[uri...@gmail.com]

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 Argon2  is theoretically superior, using it can cause compliance/auditing issues.