Will Django be a part of Google's Summer of Code 2016 program?

[Cory Kitchens]

Hello all,

My name is Cory Kitchens and I am currently a Computer Science student 
looking to contribute to the Django project this summer. I was wondering if 
there are any plans for Django to participate as an organization during the 
Google Summer of Code 2016 event? 

-- 
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/11ebb370-0f21-4b0c-9a69-bcca3e6847fd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: remove support for unsalted password hashers?

[Florian Apolloner]

Hi,

On Thursday, February 4, 2016 at 6:22:09 PM UTC+1, Raphaël Barrois wrote:
>
> Just as djangoproject.com might need to keep those old hashers around, 
> many projects will need it as well. 
> As such, providing the hashers in a dedicated "legacy" package might be 
> the solution for most projects. 
>

I'd be surprised if we still have unsalted hashes, that said, there is no 
reason to keep the old hashers around, you can easily upgrade them to 
pbkdf2 without requiring the user to log in (we actually did the same for 
salted sha when we upgraded $site).

Cheers,
Florian

-- 
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/3e404d64-8d06-453e-811c-6575747685e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: remove support for unsalted password hashers?

[Raphaël Barrois]

Hi Tim,

A few notes here:
Just as djangoproject.com might need to keep those old hashers around, many 
projects will need it as well.
As such, providing the hashers in a dedicated "legacy" package might be the 
solution for most projects.

For the deprecation process, I think the needs of most sites would be:
1) Find out how many accounts use deprecated hashes, and when they last logged 
in
2) Based on that information, decide which hashers can be removed, and which 
accounts need to have their password
reset.
Do you think this should be provided as a management command (useful as Django 
improves its hashers over the years),
or simply as a few code snippets in the release notes?

Finally, I suggest that the "no-op test hasher" retains some properties of the 
usual hashers, mainly "password is
transformed" and "any length is accepted".
Indeed, I have seen many issues with developers using ``user.password = 'foo'`` 
instead of going through
``user.set_password``; which is quickly discovered when going through the usual 
test setup.
Also, some users test for arbitrarily long passwords, which are perfectly fine 
with normal hashers and shouldn't thus
fail in a test setup due to a "no-op cleartext hasher".


If you're interested, I can provide some help with the deprecation 
documentation and no-op code in the next few days,
depending of which options you choose to go with.


-- 
Raphaël


On Wed, 3 Feb 2016 12:26:00 -0800 (PST)
Tim Graham  wrote:

> Acknowledged Donald, I just didn't want to bite off too much at once.
> 
> I think the unsalted hashers removal could be done as a 
> backwards-incompatible change. I wrote up some documentation including 
> queries to check if your database is affected: 
> https://github.com/django/django/pull/6082
> I'll be curious to know if anyone has a project that started in the Django 
> 0.90 era which returns some results for those queries.
> 
> About removing the SHA1PasswordHasher, MD5PasswordHasher, and/or 
> CryptPasswordHasher -- I suspect many more users will be affected, so the 
> normal deprecation process seems appropriate. To give an example, 8,484 
> (64%) of the passwords for djangoproject.com users are SHA1. If the SHA1 
> hasher is deprecated, what would we do? Options I can think of:
> 
> 1. copy the hasher into the djangoproject.com source
> 2. release the legacy hashers as a separate package for those projects that 
> need them
> 3. mark old passwords as unusable and force a reset if one of those users 
> comes back
> 
> The max "last login" for a user with a SHA1 hash is February 2013.
> 
> Also, the MD5PasswordHasher is suggested in the documentation as a way to 
> speed up tests so we would need to change that, whether it's force_login() 
> or some new "no-op test hasher" .
> 
> On Tuesday, February 2, 2016 at 2:20:44 PM UTC-5, Donald Stufft wrote:
> >
> >
> > On Feb 2, 2016, at 1:52 PM, Tim Graham  
> > wrote:
> >
> > Just to be clear, my proposal here is only about removing 
> > UnsaltedSHA1PasswordHasher and UnsaltedMD5PasswordHasher. The salted 
> > versions of these hashers remain.
> >
> >
> >
> > It seems silly to remove the unsalted options and leave the salted 
> > options, they are basically equally [1] as secure since computational power 
> > is such that it is, that it’s not really worth it to use rainbow tables 
> > anymore anyways.
> >
> > [1] Ok, Ok, technically salted are a wee bit more secure, but given that 
> > you can compute the MD5 of every single possible lower case alpha numeric 
> > of 6 characters or less in under a minute on a single regular 
> > desktop/server.. I don’t believe the distinction is useful.
> >
> > -
> > Donald Stufft
> > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 
> > DCFA 
> >
> >  
> 

-- 
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/20160204182155.7c3bba5e%40ithor.polyconseil.fr.
For more options, visit https://groups.google.com/d/optout.