One issue is that as far as I know, only PBKDF2 is officially approved by the NIST <http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf> 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.
On Monday, January 16, 2017 at 5:19:27 AM UTC+5:30, Tobias McNulty wrote: > > On Thu, Jan 5, 2017 at 10:58 AM, Martin Koistinen <mkois...@gmail.com > <javascript:>> 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 > <https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet#Leverage_an_adaptive_one-way_function> > and > even Django itself > <https://docs.djangoproject.com/en/1.10/releases/1.10/#django-contrib-auth>. > 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 > <https://github.com/django/deps/blob/master/draft/0007-dependency-policy.rst> > and/or the addition of the Argon2 hasher > <https://github.com/django/django/commit/b4250ea04a88f6c4fdf84dc8624baa1cf3e0f568> > > 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 > <https://github.com/django/deps/blob/master/draft/0007-dependency-policy.rst#id2> > > 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 > <https://groups.google.com/forum/#!topic/django-developers/Qab-hRG-SKs> > over time. > > Tobias > -- > > > *Tobias McNulty*Chief Executive Officer > > tob...@caktusgroup.com <javascript:> > 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/1fca9868-c0a9-45ad-baf9-c09baac11b16%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
