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

2017-01-16 Thread urijah
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.

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  > 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
>

-- 
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.


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

2017-01-16 Thread 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

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 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 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/0111a880-a8b6-4d4a-9ff5-470b2ecdca65%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2017-01-16 Thread 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* 

-- 
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/5d6087d4-e8c5-48eb-8d0e-15f3a7216b5f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2017-01-15 Thread 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.

-- 
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/562bd2ba-73eb-4abe-bd18-d994e29d306d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2017-01-15 Thread Tobias McNulty
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 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

-- 
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/CAMGFDKQxnBmMhpXFPj1QEvkocb%3D8CXsddMYP%2BjTu%2B%2BB0ce9enQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.