Re: remove support for unsalted password hashers?

[Markus Holtermann]

Cheers Tim,

looks good to me, assuming the migration actually works :-], haven't tried 
it out. We probably should advice people that running that migration 
potentially takes a while, depending on how many passwords they need to 
update.

/Markus

On Friday, February 19, 2016 at 3:52:53 AM UTC+11, Tim Graham wrote:
>
> Feedback is welcome on the draft blog post. The links to the pull requests 
> will be replaced with links to the docs once those PRs are reviewed and 
> merged.
>
> Security advisory: Strengthening the password hashes in your database
>
> Summary: If you have MD5 or SHA1 password hashes in your database, here's 
> a way to update them without requiring all your users to login again.
>
> Body:
>
> Are the password hashes in your database strong enough to prevent them 
> from being cracked if your database is compromised?
>
> Django 0.90 stored passwords as unsalted MD5. Django 0.91 added support 
> for salted SHA1 with automatic upgrade of passwords when a user logs in. 
> Django 1.4 added PBKDF2 as the default password hasher.
>
> If you have an old Django project with MD5 or SHA1 (even salted) encoded 
> passwords, be aware that these can be cracked fairly easily with today's 
> hardware. Consider using a `wrapped password hasher <
> https://github.com/django/django/pull/6114>`_ to strengthen the hashes in 
> your database. Django 1.10 will `remove the MD5 and SHA1 hashers <
> https://github.com/django/django/pull/6103>`_ from the default 
> ``PASSWORD_HASHERS`` setting to force projects to acknowledge continued use 
> of a weak hasher.
>
> On Wednesday, February 17, 2016 at 1:24:04 PM UTC-5, Tim Graham wrote:
>>
>> To answer my own question, I did a little experiment and cracked about 
>> 10% of the SHA1 password hashes in the djangoproject.com database in 
>> minutes on my several year old PC.
>>
>> I think that's sufficiently weak to:
>> 1. Make a blog post recommending that projects upgrade using the 
>> instructions in [1] 
>> 2. Remove SHA1PasswordHasher from the default PASSWORD_HASHERS in Django 
>> 1.10 to force projects to explicitly acknowledge use of an insecure hash if 
>> they require it.
>>
>> [1] https://github.com/django/django/pull/6114
>>
>> On Wednesday, February 10, 2016 at 5:16:11 PM UTC-5, Tim Graham wrote:
>>>
>>> Is salted SHA1 sufficiently insecure to remove it from the default 
>>> PASSWORD_HASHERS or should we leave it for now? Any project created before 
>>> pbkdf2 was introduced in Django 1.4 (March 2012) will likely have some SHA1 
>>> hashes unless all their users have logged in since. I've written 
>>> instructions on how to upgrade such passwords without requiring all your 
>>> users to login [1]. If it's warranted, we could make a blog post advising 
>>> this. 
>>>
>>> [1] https://github.com/django/django/pull/6114 
>>> 
>>>
>>> On Monday, February 8, 2016 at 3:12:28 PM UTC-5, Tim Graham wrote:

 Thanks for the feedback everyone. I've created a few action items:

 https://code.djangoproject.com/ticket/26187 - Remove weak password 
 hashers from the default PASSWORD_HASHERS setting
 https://code.djangoproject.com/ticket/26188 - Document how to wrap 
 password hashers
 https://github.com/django/djangoproject.com/issues/632 - Use a wrapped 
 password hasher to upgrade SHA1 passwords

 On Saturday, February 6, 2016 at 3:56:00 AM UTC-5, Curtis Maloney wrote:
>
> I kept meaning to weigh in on this... but all my points have been 
> made. 
>
> It sounds like the middle ground is to: 
>
> 1) remove them from the default list 
> 2) keep them in the codebase 
> 3) make them noisy (raise warnings) 
> 4) provide docs/tools on how to upgrade 
>
> Then we get "secure by default" (1), as well as "encouraging upgrades" 
> (3), whilst also "supporting slow-to-update installs" (4), and 
> "encouraging best practices" (3). 
>
>
> -- 
> C 
>
>
> On 06/02/16 19:51, Aymeric Augustin wrote: 
> > Yes, that would be good from the “security by default” standpoint. 
> This 
> > would also allow us to trim the full list of hashers which is 
> repeated 
> > several times in the docs. 
> > 
> > -- 
> > Aymeric. 
> > 
> >> On 6 févr. 2016, at 00:03, Tim Graham  >> > wrote: 
> >> 
> >> I would guess most users aren't customizing the default list of 
> >> hashers, so I'd rather remove weak hashers from the 
> PASSWORD_HASHERS 
> >> setting and let anyone who needs to use a weak hasher define their 
> own 
> >> setting (at which point a warning probably isn't needed). Does that 
> >> seem okay? 
> >> 
> >> On Friday, February 5, 2016 at 3:20:41 PM UTC-5, Aymeric Augustin 
> wrote: 
> >> 
> >> 

Re: remove support for unsalted password hashers?

[Tim Graham]

Feedback is welcome on the draft blog post. The links to the pull requests 
will be replaced with links to the docs once those PRs are reviewed and 
merged.

Security advisory: Strengthening the password hashes in your database

Summary: If you have MD5 or SHA1 password hashes in your database, here's a 
way to update them without requiring all your users to login again.

Body:

Are the password hashes in your database strong enough to prevent them from 
being cracked if your database is compromised?

Django 0.90 stored passwords as unsalted MD5. Django 0.91 added support for 
salted SHA1 with automatic upgrade of passwords when a user logs in. Django 
1.4 added PBKDF2 as the default password hasher.

If you have an old Django project with MD5 or SHA1 (even salted) encoded 
passwords, be aware that these can be cracked fairly easily with today's 
hardware. Consider using a `wrapped password hasher 
`_ to strengthen the hashes in 
your database. Django 1.10 will `remove the MD5 and SHA1 hashers 
`_ from the default 
``PASSWORD_HASHERS`` setting to force projects to acknowledge continued use 
of a weak hasher.

On Wednesday, February 17, 2016 at 1:24:04 PM UTC-5, Tim Graham wrote:
>
> To answer my own question, I did a little experiment and cracked about 10% 
> of the SHA1 password hashes in the djangoproject.com database in minutes 
> on my several year old PC.
>
> I think that's sufficiently weak to:
> 1. Make a blog post recommending that projects upgrade using the 
> instructions in [1] 
> 2. Remove SHA1PasswordHasher from the default PASSWORD_HASHERS in Django 
> 1.10 to force projects to explicitly acknowledge use of an insecure hash if 
> they require it.
>
> [1] https://github.com/django/django/pull/6114
>
> On Wednesday, February 10, 2016 at 5:16:11 PM UTC-5, Tim Graham wrote:
>>
>> Is salted SHA1 sufficiently insecure to remove it from the default 
>> PASSWORD_HASHERS or should we leave it for now? Any project created before 
>> pbkdf2 was introduced in Django 1.4 (March 2012) will likely have some SHA1 
>> hashes unless all their users have logged in since. I've written 
>> instructions on how to upgrade such passwords without requiring all your 
>> users to login [1]. If it's warranted, we could make a blog post advising 
>> this. 
>>
>> [1] https://github.com/django/django/pull/6114 
>> 
>>
>> On Monday, February 8, 2016 at 3:12:28 PM UTC-5, Tim Graham wrote:
>>>
>>> Thanks for the feedback everyone. I've created a few action items:
>>>
>>> https://code.djangoproject.com/ticket/26187 - Remove weak password 
>>> hashers from the default PASSWORD_HASHERS setting
>>> https://code.djangoproject.com/ticket/26188 - Document how to wrap 
>>> password hashers
>>> https://github.com/django/djangoproject.com/issues/632 - Use a wrapped 
>>> password hasher to upgrade SHA1 passwords
>>>
>>> On Saturday, February 6, 2016 at 3:56:00 AM UTC-5, Curtis Maloney wrote:

 I kept meaning to weigh in on this... but all my points have been made. 

 It sounds like the middle ground is to: 

 1) remove them from the default list 
 2) keep them in the codebase 
 3) make them noisy (raise warnings) 
 4) provide docs/tools on how to upgrade 

 Then we get "secure by default" (1), as well as "encouraging upgrades" 
 (3), whilst also "supporting slow-to-update installs" (4), and 
 "encouraging best practices" (3). 


 -- 
 C 


 On 06/02/16 19:51, Aymeric Augustin wrote: 
 > Yes, that would be good from the “security by default” standpoint. 
 This 
 > would also allow us to trim the full list of hashers which is 
 repeated 
 > several times in the docs. 
 > 
 > -- 
 > Aymeric. 
 > 
 >> On 6 févr. 2016, at 00:03, Tim Graham > > wrote: 
 >> 
 >> I would guess most users aren't customizing the default list of 
 >> hashers, so I'd rather remove weak hashers from the PASSWORD_HASHERS 
 >> setting and let anyone who needs to use a weak hasher define their 
 own 
 >> setting (at which point a warning probably isn't needed). Does that 
 >> seem okay? 
 >> 
 >> On Friday, February 5, 2016 at 3:20:41 PM UTC-5, Aymeric Augustin 
 wrote: 
 >> 
 >> Adding a check for weak password hashers could be a good 
 >> compromise to drive attention to the issue but make it 
 reasonably 
 >> easy to ignore it if you need MD5 for compatibility with other 
 >> systems. 
 >> 
 >> -- 
 >> Aymeric. 
 >> 
 >>> On 5 févr. 2016, at 21:11, Sergei Maertens <
 sergeim...@gmail.com 
 >>> > wrote: 
 >>> 
 >>> This is my main concern as well. I 

Re: remove support for unsalted password hashers?

[Tim Graham]

To answer my own question, I did a little experiment and cracked about 10% 
of the SHA1 password hashes in the djangoproject.com database in minutes on 
my several year old PC.

I think that's sufficiently weak to:
1. Make a blog post recommending that projects upgrade using the 
instructions in [1] 
2. Remove SHA1PasswordHasher from the default PASSWORD_HASHERS in Django 
1.10 to force projects to explicitly acknowledge use of an insecure hash if 
they require it.

[1] https://github.com/django/django/pull/6114

On Wednesday, February 10, 2016 at 5:16:11 PM UTC-5, Tim Graham wrote:
>
> Is salted SHA1 sufficiently insecure to remove it from the default 
> PASSWORD_HASHERS or should we leave it for now? Any project created before 
> pbkdf2 was introduced in Django 1.4 (March 2012) will likely have some SHA1 
> hashes unless all their users have logged in since. I've written 
> instructions on how to upgrade such passwords without requiring all your 
> users to login [1]. If it's warranted, we could make a blog post advising 
> this. 
>
> [1] https://github.com/django/django/pull/6114 
> 
>
> On Monday, February 8, 2016 at 3:12:28 PM UTC-5, Tim Graham wrote:
>>
>> Thanks for the feedback everyone. I've created a few action items:
>>
>> https://code.djangoproject.com/ticket/26187 - Remove weak password 
>> hashers from the default PASSWORD_HASHERS setting
>> https://code.djangoproject.com/ticket/26188 - Document how to wrap 
>> password hashers
>> https://github.com/django/djangoproject.com/issues/632 - Use a wrapped 
>> password hasher to upgrade SHA1 passwords
>>
>> On Saturday, February 6, 2016 at 3:56:00 AM UTC-5, Curtis Maloney wrote:
>>>
>>> I kept meaning to weigh in on this... but all my points have been made. 
>>>
>>> It sounds like the middle ground is to: 
>>>
>>> 1) remove them from the default list 
>>> 2) keep them in the codebase 
>>> 3) make them noisy (raise warnings) 
>>> 4) provide docs/tools on how to upgrade 
>>>
>>> Then we get "secure by default" (1), as well as "encouraging upgrades" 
>>> (3), whilst also "supporting slow-to-update installs" (4), and 
>>> "encouraging best practices" (3). 
>>>
>>>
>>> -- 
>>> C 
>>>
>>>
>>> On 06/02/16 19:51, Aymeric Augustin wrote: 
>>> > Yes, that would be good from the “security by default” standpoint. 
>>> This 
>>> > would also allow us to trim the full list of hashers which is repeated 
>>> > several times in the docs. 
>>> > 
>>> > -- 
>>> > Aymeric. 
>>> > 
>>> >> On 6 févr. 2016, at 00:03, Tim Graham >> >> > wrote: 
>>> >> 
>>> >> I would guess most users aren't customizing the default list of 
>>> >> hashers, so I'd rather remove weak hashers from the PASSWORD_HASHERS 
>>> >> setting and let anyone who needs to use a weak hasher define their 
>>> own 
>>> >> setting (at which point a warning probably isn't needed). Does that 
>>> >> seem okay? 
>>> >> 
>>> >> On Friday, February 5, 2016 at 3:20:41 PM UTC-5, Aymeric Augustin 
>>> wrote: 
>>> >> 
>>> >> Adding a check for weak password hashers could be a good 
>>> >> compromise to drive attention to the issue but make it reasonably 
>>> >> easy to ignore it if you need MD5 for compatibility with other 
>>> >> systems. 
>>> >> 
>>> >> -- 
>>> >> Aymeric. 
>>> >> 
>>> >>> On 5 févr. 2016, at 21:11, Sergei Maertens >> >>> > wrote: 
>>> >>> 
>>> >>> This is my main concern as well. I often migrate old Joomla or 
>>> >>> other PHP things that use md5, and it's really convenient that 
>>> >>> Django upgrades the passwords for free for me. 
>>> >>> 
>>> >>> Although I guess I could just write the hasher as part of the 
>>> >>> project and add it to the setting, but then that's an additional 
>>> >>> burding because you need to keep track of potential new hashers 
>>> >>> that get added in the default settings. 
>>> >>> 
>>> >>> On Friday, February 5, 2016 at 1:05:01 PM UTC+1, Rafał Pitoń 
>>> wrote: 
>>> >>> 
>>> >>> Will I still be able to implement unsalted hasher if I so 
>>> desire? 
>>> >>> 
>>> >>> Don't get me wrong, I understand thats pretty crappy way to 
>>> >>> store password, but there are times when you inherit large 
>>> >>> set of data from site that you are moving from some old PHP 
>>> >>> contraption that happens to be around since 2006, is big 
>>> >>> (>100 users), ran by company that dominates one of 
>>> >>> nation's markets and says "absolutely no" on making all 
>>> those 
>>> >>> housewifes reset passwords, and your passwords happen to use 
>>> >>> md5(md5(pass) + md5(pass)) for passwords? 
>>> >>> 
>>> >>> 
>>> >>> -- 
>>> >>> You received this message because you are subscribed to the 
>>> >>> Google Groups "Django developers 

Re: remove support for unsalted password hashers?

[Tim Graham]

Is salted SHA1 sufficiently insecure to remove it from the default 
PASSWORD_HASHERS or should we leave it for now? Any project created before 
pbkdf2 was introduced in Django 1.4 (March 2012) will likely have some SHA1 
hashes unless all their users have logged in since. I've written 
instructions on how to upgrade such passwords without requiring all your 
users to login [1]. If it's warranted, we could make a blog post advising 
this. 

[1] https://github.com/django/django/pull/6114

On Monday, February 8, 2016 at 3:12:28 PM UTC-5, Tim Graham wrote:
>
> Thanks for the feedback everyone. I've created a few action items:
>
> https://code.djangoproject.com/ticket/26187 - Remove weak password 
> hashers from the default PASSWORD_HASHERS setting
> https://code.djangoproject.com/ticket/26188 - Document how to wrap 
> password hashers
> https://github.com/django/djangoproject.com/issues/632 - Use a wrapped 
> password hasher to upgrade SHA1 passwords
>
> On Saturday, February 6, 2016 at 3:56:00 AM UTC-5, Curtis Maloney wrote:
>>
>> I kept meaning to weigh in on this... but all my points have been made. 
>>
>> It sounds like the middle ground is to: 
>>
>> 1) remove them from the default list 
>> 2) keep them in the codebase 
>> 3) make them noisy (raise warnings) 
>> 4) provide docs/tools on how to upgrade 
>>
>> Then we get "secure by default" (1), as well as "encouraging upgrades" 
>> (3), whilst also "supporting slow-to-update installs" (4), and 
>> "encouraging best practices" (3). 
>>
>>
>> -- 
>> C 
>>
>>
>> On 06/02/16 19:51, Aymeric Augustin wrote: 
>> > Yes, that would be good from the “security by default” standpoint. This 
>> > would also allow us to trim the full list of hashers which is repeated 
>> > several times in the docs. 
>> > 
>> > -- 
>> > Aymeric. 
>> > 
>> >> On 6 févr. 2016, at 00:03, Tim Graham > >> > wrote: 
>> >> 
>> >> I would guess most users aren't customizing the default list of 
>> >> hashers, so I'd rather remove weak hashers from the PASSWORD_HASHERS 
>> >> setting and let anyone who needs to use a weak hasher define their own 
>> >> setting (at which point a warning probably isn't needed). Does that 
>> >> seem okay? 
>> >> 
>> >> On Friday, February 5, 2016 at 3:20:41 PM UTC-5, Aymeric Augustin 
>> wrote: 
>> >> 
>> >> Adding a check for weak password hashers could be a good 
>> >> compromise to drive attention to the issue but make it reasonably 
>> >> easy to ignore it if you need MD5 for compatibility with other 
>> >> systems. 
>> >> 
>> >> -- 
>> >> Aymeric. 
>> >> 
>> >>> On 5 févr. 2016, at 21:11, Sergei Maertens > >>> > wrote: 
>> >>> 
>> >>> This is my main concern as well. I often migrate old Joomla or 
>> >>> other PHP things that use md5, and it's really convenient that 
>> >>> Django upgrades the passwords for free for me. 
>> >>> 
>> >>> Although I guess I could just write the hasher as part of the 
>> >>> project and add it to the setting, but then that's an additional 
>> >>> burding because you need to keep track of potential new hashers 
>> >>> that get added in the default settings. 
>> >>> 
>> >>> On Friday, February 5, 2016 at 1:05:01 PM UTC+1, Rafał Pitoń 
>> wrote: 
>> >>> 
>> >>> Will I still be able to implement unsalted hasher if I so 
>> desire? 
>> >>> 
>> >>> Don't get me wrong, I understand thats pretty crappy way to 
>> >>> store password, but there are times when you inherit large 
>> >>> set of data from site that you are moving from some old PHP 
>> >>> contraption that happens to be around since 2006, is big 
>> >>> (>100 users), ran by company that dominates one of 
>> >>> nation's markets and says "absolutely no" on making all those 
>> >>> housewifes reset passwords, and your passwords happen to use 
>> >>> md5(md5(pass) + md5(pass)) for passwords? 
>> >>> 
>> >>> 
>> >>> -- 
>> >>> 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-develop...@googlegroups.com 
>> . 
>> >>> To post to this group, send email to django-d...@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/56677162-c020-4c2f-8d1f-b35ec0b9874d%40googlegroups.com
>>  
>> >>> <
>> https://groups.google.com/d/msgid/django-developers/56677162-c020-4c2f-8d1f-b35ec0b9874d%40googlegroups.com?utm_medium=email_source=footer>.
>>  
>>
>> >>> For more options, visit 

Re: remove support for unsalted password hashers?

[Tim Graham]

Thanks for the feedback everyone. I've created a few action items:

https://code.djangoproject.com/ticket/26187 - Remove weak password hashers 
from the default PASSWORD_HASHERS setting
https://code.djangoproject.com/ticket/26188 - Document how to wrap password 
hashers
https://github.com/django/djangoproject.com/issues/632 - Use a wrapped 
password hasher to upgrade SHA1 passwords

On Saturday, February 6, 2016 at 3:56:00 AM UTC-5, Curtis Maloney wrote:
>
> I kept meaning to weigh in on this... but all my points have been made. 
>
> It sounds like the middle ground is to: 
>
> 1) remove them from the default list 
> 2) keep them in the codebase 
> 3) make them noisy (raise warnings) 
> 4) provide docs/tools on how to upgrade 
>
> Then we get "secure by default" (1), as well as "encouraging upgrades" 
> (3), whilst also "supporting slow-to-update installs" (4), and 
> "encouraging best practices" (3). 
>
>
> -- 
> C 
>
>
> On 06/02/16 19:51, Aymeric Augustin wrote: 
> > Yes, that would be good from the “security by default” standpoint. This 
> > would also allow us to trim the full list of hashers which is repeated 
> > several times in the docs. 
> > 
> > -- 
> > Aymeric. 
> > 
> >> On 6 févr. 2016, at 00:03, Tim Graham  >> > wrote: 
> >> 
> >> I would guess most users aren't customizing the default list of 
> >> hashers, so I'd rather remove weak hashers from the PASSWORD_HASHERS 
> >> setting and let anyone who needs to use a weak hasher define their own 
> >> setting (at which point a warning probably isn't needed). Does that 
> >> seem okay? 
> >> 
> >> On Friday, February 5, 2016 at 3:20:41 PM UTC-5, Aymeric Augustin 
> wrote: 
> >> 
> >> Adding a check for weak password hashers could be a good 
> >> compromise to drive attention to the issue but make it reasonably 
> >> easy to ignore it if you need MD5 for compatibility with other 
> >> systems. 
> >> 
> >> -- 
> >> Aymeric. 
> >> 
> >>> On 5 févr. 2016, at 21:11, Sergei Maertens  >>> > wrote: 
> >>> 
> >>> This is my main concern as well. I often migrate old Joomla or 
> >>> other PHP things that use md5, and it's really convenient that 
> >>> Django upgrades the passwords for free for me. 
> >>> 
> >>> Although I guess I could just write the hasher as part of the 
> >>> project and add it to the setting, but then that's an additional 
> >>> burding because you need to keep track of potential new hashers 
> >>> that get added in the default settings. 
> >>> 
> >>> On Friday, February 5, 2016 at 1:05:01 PM UTC+1, Rafał Pitoń 
> wrote: 
> >>> 
> >>> Will I still be able to implement unsalted hasher if I so 
> desire? 
> >>> 
> >>> Don't get me wrong, I understand thats pretty crappy way to 
> >>> store password, but there are times when you inherit large 
> >>> set of data from site that you are moving from some old PHP 
> >>> contraption that happens to be around since 2006, is big 
> >>> (>100 users), ran by company that dominates one of 
> >>> nation's markets and says "absolutely no" on making all those 
> >>> housewifes reset passwords, and your passwords happen to use 
> >>> md5(md5(pass) + md5(pass)) for passwords? 
> >>> 
> >>> 
> >>> -- 
> >>> 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-develop...@googlegroups.com 
> . 
> >>> To post to this group, send email to django-d...@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/56677162-c020-4c2f-8d1f-b35ec0b9874d%40googlegroups.com
>  
> >>> <
> https://groups.google.com/d/msgid/django-developers/56677162-c020-4c2f-8d1f-b35ec0b9874d%40googlegroups.com?utm_medium=email_source=footer>.
>  
>
> >>> For more options, visit https://groups.google.com/d/optout 
> >>> . 
> >> 
> >> 
> >> -- 
> >> 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-develop...@googlegroups.com  
> >> . 
> >> To post to this group, send email to 
> >> django-d...@googlegroups.com  
> >> . 
> >> Visit this group at https://groups.google.com/group/django-developers. 
> >> To view this discussion on the web 

Re: remove support for unsalted password hashers?

[Curtis Maloney]

I kept meaning to weigh in on this... but all my points have been made.

It sounds like the middle ground is to:

1) remove them from the default list
2) keep them in the codebase
3) make them noisy (raise warnings)
4) provide docs/tools on how to upgrade

Then we get "secure by default" (1), as well as "encouraging upgrades" 
(3), whilst also "supporting slow-to-update installs" (4), and 
"encouraging best practices" (3).



--
C


On 06/02/16 19:51, Aymeric Augustin wrote:

Yes, that would be good from the “security by default” standpoint. This
would also allow us to trim the full list of hashers which is repeated
several times in the docs.

--
Aymeric.


On 6 févr. 2016, at 00:03, Tim Graham > wrote:

I would guess most users aren't customizing the default list of
hashers, so I'd rather remove weak hashers from the PASSWORD_HASHERS
setting and let anyone who needs to use a weak hasher define their own
setting (at which point a warning probably isn't needed). Does that
seem okay?

On Friday, February 5, 2016 at 3:20:41 PM UTC-5, Aymeric Augustin wrote:

Adding a check for weak password hashers could be a good
compromise to drive attention to the issue but make it reasonably
easy to ignore it if you need MD5 for compatibility with other
systems.

--
Aymeric.


On 5 févr. 2016, at 21:11, Sergei Maertens  wrote:

This is my main concern as well. I often migrate old Joomla or
other PHP things that use md5, and it's really convenient that
Django upgrades the passwords for free for me.

Although I guess I could just write the hasher as part of the
project and add it to the setting, but then that's an additional
burding because you need to keep track of potential new hashers
that get added in the default settings.

On Friday, February 5, 2016 at 1:05:01 PM UTC+1, Rafał Pitoń wrote:

Will I still be able to implement unsalted hasher if I so desire?

Don't get me wrong, I understand thats pretty crappy way to
store password, but there are times when you inherit large
set of data from site that you are moving from some old PHP
contraption that happens to be around since 2006, is big
(>100 users), ran by company that dominates one of
nation's markets and says "absolutely no" on making all those
housewifes reset passwords, and your passwords happen to use
md5(md5(pass) + md5(pass)) for passwords?


--
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-develop...@googlegroups.com .
To post to this group, send email to django-d...@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/56677162-c020-4c2f-8d1f-b35ec0b9874d%40googlegroups.com

.
For more options, visit https://groups.google.com/d/optout
.



--
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/9e184cd6-69cc-4fe8-835e-055bc7121ac9%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.


--
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/5081977A-64B0-4443-ADDE-CEFCC5704E72%40polytechnique.org

Re: remove support for unsalted password hashers?

[Aymeric Augustin]

Yes, that would be good from the “security by default” standpoint. This would 
also allow us to trim the full list of hashers which is repeated several times 
in the docs.

-- 
Aymeric.

> On 6 févr. 2016, at 00:03, Tim Graham  wrote:
> 
> I would guess most users aren't customizing the default list of hashers, so 
> I'd rather remove weak hashers from the PASSWORD_HASHERS setting and let 
> anyone who needs to use a weak hasher define their own setting (at which 
> point a warning probably isn't needed). Does that seem okay?
> 
> On Friday, February 5, 2016 at 3:20:41 PM UTC-5, Aymeric Augustin wrote:
> Adding a check for weak password hashers could be a good compromise to drive 
> attention to the issue but make it reasonably easy to ignore it if you need 
> MD5 for compatibility with other systems.
> 
> -- 
> Aymeric.
> 
>> On 5 févr. 2016, at 21:11, Sergei Maertens > > wrote:
>> 
>> This is my main concern as well. I often migrate old Joomla or other PHP 
>> things that use md5, and it's really convenient that Django upgrades the 
>> passwords for free for me.
>> 
>> Although I guess I could just write the hasher as part of the project and 
>> add it to the setting, but then that's an additional burding because you 
>> need to keep track of potential new hashers that get added in the default 
>> settings.
>> 
>> On Friday, February 5, 2016 at 1:05:01 PM UTC+1, Rafał Pitoń wrote:
>> Will I still be able to implement unsalted hasher if I so desire?
>> 
>> Don't get me wrong, I understand thats pretty crappy way to store password, 
>> but there are times when you inherit large set of data from site that you 
>> are moving from some old PHP contraption that happens to be around since 
>> 2006, is big (>100 users), ran by company that dominates one of nation's 
>> markets and says "absolutely no" on making all those housewifes reset 
>> passwords, and your passwords happen to use md5(md5(pass) + md5(pass)) for 
>> passwords?
>> 
>> -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@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/56677162-c020-4c2f-8d1f-b35ec0b9874d%40googlegroups.com
>>  
>> .
>> For more options, visit https://groups.google.com/d/optout 
>> .
> 
> 
> -- 
> 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/9e184cd6-69cc-4fe8-835e-055bc7121ac9%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
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/5081977A-64B0-4443-ADDE-CEFCC5704E72%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: remove support for unsalted password hashers?

[Tim Graham]

I would guess most users aren't customizing the default list of hashers, so 
I'd rather remove weak hashers from the PASSWORD_HASHERS setting and let 
anyone who needs to use a weak hasher define their own setting (at which 
point a warning probably isn't needed). Does that seem okay?

On Friday, February 5, 2016 at 3:20:41 PM UTC-5, Aymeric Augustin wrote:
>
> Adding a check for weak password hashers could be a good compromise to 
> drive attention to the issue but make it reasonably easy to ignore it if 
> you need MD5 for compatibility with other systems.
>
> -- 
> Aymeric.
>
> On 5 févr. 2016, at 21:11, Sergei Maertens  > wrote:
>
> This is my main concern as well. I often migrate old Joomla or other PHP 
> things that use md5, and it's really convenient that Django upgrades the 
> passwords for free for me.
>
> Although I guess I could just write the hasher as part of the project and 
> add it to the setting, but then that's an additional burding because you 
> need to keep track of potential new hashers that get added in the default 
> settings.
>
> On Friday, February 5, 2016 at 1:05:01 PM UTC+1, Rafał Pitoń wrote:
>>
>> Will I still be able to implement unsalted hasher if I so desire?
>>
>> Don't get me wrong, I understand thats pretty crappy way to store 
>> password, but there are times when you inherit large set of data from site 
>> that you are moving from some old PHP contraption that happens to be around 
>> since 2006, is big (>100 users), ran by company that dominates one of 
>> nation's markets and says "absolutely no" on making all those housewifes 
>> reset passwords, and your passwords happen to use md5(md5(pass) + 
>> md5(pass)) for passwords?
>>
>
> -- 
> 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-develop...@googlegroups.com .
> To post to this group, send email to django-d...@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/56677162-c020-4c2f-8d1f-b35ec0b9874d%40googlegroups.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
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/9e184cd6-69cc-4fe8-835e-055bc7121ac9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: remove support for unsalted password hashers?

[Aymeric Augustin]

Adding a check for weak password hashers could be a good compromise to drive 
attention to the issue but make it reasonably easy to ignore it if you need MD5 
for compatibility with other systems.

-- 
Aymeric.

> On 5 févr. 2016, at 21:11, Sergei Maertens  wrote:
> 
> This is my main concern as well. I often migrate old Joomla or other PHP 
> things that use md5, and it's really convenient that Django upgrades the 
> passwords for free for me.
> 
> Although I guess I could just write the hasher as part of the project and add 
> it to the setting, but then that's an additional burding because you need to 
> keep track of potential new hashers that get added in the default settings.
> 
> On Friday, February 5, 2016 at 1:05:01 PM UTC+1, Rafał Pitoń wrote:
> Will I still be able to implement unsalted hasher if I so desire?
> 
> Don't get me wrong, I understand thats pretty crappy way to store password, 
> but there are times when you inherit large set of data from site that you are 
> moving from some old PHP contraption that happens to be around since 2006, is 
> big (>100 users), ran by company that dominates one of nation's markets 
> and says "absolutely no" on making all those housewifes reset passwords, and 
> your passwords happen to use md5(md5(pass) + md5(pass)) for passwords?
> 
> -- 
> 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/56677162-c020-4c2f-8d1f-b35ec0b9874d%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
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/0A64944E-6096-4C90-A3F6-DBC8BB45B6FD%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: remove support for unsalted password hashers?

[Sergei Maertens]

This is my main concern as well. I often migrate old Joomla or other PHP 
things that use md5, and it's really convenient that Django upgrades the 
passwords for free for me.

Although I guess I could just write the hasher as part of the project and 
add it to the setting, but then that's an additional burding because you 
need to keep track of potential new hashers that get added in the default 
settings.

On Friday, February 5, 2016 at 1:05:01 PM UTC+1, Rafał Pitoń wrote:
>
> Will I still be able to implement unsalted hasher if I so desire?
>
> Don't get me wrong, I understand thats pretty crappy way to store 
> password, but there are times when you inherit large set of data from site 
> that you are moving from some old PHP contraption that happens to be around 
> since 2006, is big (>100 users), ran by company that dominates one of 
> nation's markets and says "absolutely no" on making all those housewifes 
> reset passwords, and your passwords happen to use md5(md5(pass) + 
> md5(pass)) for passwords?
>

-- 
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/56677162-c020-4c2f-8d1f-b35ec0b9874d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: remove support for unsalted password hashers?

[Tim Graham]

I was thinking of a situation where you have md5 hashes in the database and 
want to run both Django and the legacy system at the same time. In that 
case, changing the password format in the database might not be an option 
if the legacy system needs to read plain hashes instead of Django's format. 
Maybe this isn't important to support. I thought it might be possible using 
the unsalted md5 hasher with algorithm='' but this givers 
ImproperlyConfigured("hasher doesn't specify an algorithm name").

On Friday, February 5, 2016 at 10:05:31 AM UTC-5, Donald Stufft wrote:
>
>
> > On Feb 5, 2016, at 10:04 AM, Tim Graham  > wrote: 
> > 
> > I'm not sure if we can keep support for unsalted hashes while removing 
> the special logic in identify_hasher() for those hashers since they don't 
> confirm to Django's normal hash format? 
> > 
> https://github.com/django/django/pull/6082/files#diff-2f01db46550174ad3e55be7070b98ec9
>  
> > 
> > I guess a use case where you are integrating with a legacy system that 
> doesn't allow upgrading of passwords wouldn't allow the "wrapping hashers" 
> technique. 
>
> Seems like it would be trivial to migrate the database to make the hashed 
> password conform to the format. 
>
> - 
> 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/49c680fb-3154-43d6-9dc1-3e46dc2f2b6d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: remove support for unsalted password hashers?

[Tim Graham]

I'm not sure if we can keep support for unsalted hashes while removing the 
special logic in identify_hasher() for those hashers since they don't 
confirm to Django's normal hash format?
https://github.com/django/django/pull/6082/files#diff-2f01db46550174ad3e55be7070b98ec9

I guess a use case where you are integrating with a legacy system that 
doesn't allow upgrading of passwords wouldn't allow the "wrapping hashers" 
technique.

On Friday, February 5, 2016 at 9:38:23 AM UTC-5, Donald Stufft wrote:
>
> > 
> > On Feb 5, 2016, at 7:05 AM, Rafał Pitoń  > wrote: 
> > 
> > Will I still be able to implement unsalted hasher if I so desire? 
> > 
> > Don't get me wrong, I understand thats pretty crappy way to store 
> password, but there are times when you inherit large set of data from site 
> that you are moving from some old PHP contraption that happens to be around 
> since 2006, is big (>100 users), ran by company that dominates one of 
> nation's markets and says "absolutely no" on making all those housewifes 
> reset passwords, and your passwords happen to use md5(md5(pass) + 
> md5(pass)) for passwords? 
>
>
> You can implement them still sure, there’s nothing stopping you. 
>
>
> You can also do bcrypt(md5(md5(pass) + md5(pass)) and then you’ve fixed 
> the issue without needing to issue a password reset. 
>
> - 
> 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/b3575cfa-ad79-42b0-9336-8f5bf31a6e55%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: remove support for unsalted password hashers?

[Donald Stufft]

> On Feb 5, 2016, at 10:04 AM, Tim Graham  wrote:
> 
> I'm not sure if we can keep support for unsalted hashes while removing the 
> special logic in identify_hasher() for those hashers since they don't confirm 
> to Django's normal hash format?
> https://github.com/django/django/pull/6082/files#diff-2f01db46550174ad3e55be7070b98ec9
> 
> I guess a use case where you are integrating with a legacy system that 
> doesn't allow upgrading of passwords wouldn't allow the "wrapping hashers" 
> technique.

Seems like it would be trivial to migrate the database to make the hashed 
password conform to the format.

-
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/196F5D27-B720-4D9E-8EC4-074B18E9E8E2%40stufft.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: remove support for unsalted password hashers?

[Donald Stufft]

> 
> On Feb 5, 2016, at 7:05 AM, Rafał Pitoń  wrote:
> 
> Will I still be able to implement unsalted hasher if I so desire?
> 
> Don't get me wrong, I understand thats pretty crappy way to store password, 
> but there are times when you inherit large set of data from site that you are 
> moving from some old PHP contraption that happens to be around since 2006, is 
> big (>100 users), ran by company that dominates one of nation's markets 
> and says "absolutely no" on making all those housewifes reset passwords, and 
> your passwords happen to use md5(md5(pass) + md5(pass)) for passwords?


You can implement them still sure, there’s nothing stopping you.


You can also do bcrypt(md5(md5(pass) + md5(pass)) and then you’ve fixed the 
issue without needing to issue a password reset.

-
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/0A69E02C-F025-4E4B-9709-8D135BA5539C%40stufft.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

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.

Re: remove support for unsalted password hashers?

[Tim Graham]

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/66c31c07-5f7b-4817-83e8-2e7a5660ec97%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: remove support for unsalted password hashers?

[charettes]

> For testing, Django provides force_login(). This method skips password 
hashing
> and logs a user in for a test. For tests that want a logged in user and 
do not
> care about how the password was verified, this seems like a good choice.
> Assuming this was used throughout, would this be sufficient for handling 
this
> performance concern? 

I didn't know about that force_login() method. I see that a lot of admin 
tests
have been converted to use it so far which is great but there's still a 
couple
of occurence of login() that looks like they could be converted.

> Tests that verify the password hasher will need to run the hash algorithm
> regardless.

I'm aware of that but this only represents a small fraction of the tests.

Le mardi 2 février 2016 13:49:31 UTC-5, Jon Dufresne a écrit :
>
> On Tue, Feb 2, 2016 at 10:35 AM, charettes  > wrote: 
> >> That hasher, being the fastest non-plaintext hasher around, is quite 
> >> useful 
> >> when running tests: it allows login checks to be performed much faster. 
> > 
> > This argument came up a couple of time in the past and from what I 
> remember 
> > the Django test suite itself spends a significant amount of time hashing 
> > passwords. 
> > 
> > I understand that we want to avoid shipping a plaintext password hasher 
> in 
> > `django.contrib.auth.hashers` for the sake of not exposing a footgun-API 
> but 
> > what if we shipped one in the `django.contrib.auth.test` package 
> instead? 
> > 
> > We could document its use for testing purposes only and would make the 
> > complete deprecation of unsafe hashers easier. 
>
> For testing, Django provides force_login(). This method skips password 
> hashing and logs a user in for a test. For tests that want a logged in 
> user and do not care about how the password was verified, this seems 
> like a good choice. Assuming this was used throughout, would this be 
> sufficient for handling this performance concern? 
>
> Tests that verify the password hasher will need to run the hash 
> algorithm regardless. 
>
>
> https://docs.djangoproject.com/en/1.9/topics/testing/tools/#django.test.Client.force_login
>  
>

-- 
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/57f549d2-7eb3-4300-9e7e-c0aad97b0bf8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: remove support for unsalted password hashers?

[charettes]

> For testing, Django provides force_login(). This method skips password 
hashing
> and logs a user in for a test. For tests that want a logged in user and 
do not
> care about how the password was verified, this seems like a good choice.
> Assuming this was used throughout, would this be sufficient for handling 
this
> performance concern? 

I didn't know about that force_login() method. I see that a lot of admin 
tests
have been converted to use it so far which is great but there's still a 
couple
of occurence of login() that looks like they could be converted.

> Tests that verify the password hasher will need to run the hash algorithm
> regardless.

I'm aware of that but this only represents a small fraction of the tests.

Le mardi 2 février 2016 13:49:31 UTC-5, Jon Dufresne a écrit :
>
> On Tue, Feb 2, 2016 at 10:35 AM, charettes  > wrote: 
> >> That hasher, being the fastest non-plaintext hasher around, is quite 
> >> useful 
> >> when running tests: it allows login checks to be performed much faster. 
> > 
> > This argument came up a couple of time in the past and from what I 
> remember 
> > the Django test suite itself spends a significant amount of time hashing 
> > passwords. 
> > 
> > I understand that we want to avoid shipping a plaintext password hasher 
> in 
> > `django.contrib.auth.hashers` for the sake of not exposing a footgun-API 
> but 
> > what if we shipped one in the `django.contrib.auth.test` package 
> instead? 
> > 
> > We could document its use for testing purposes only and would make the 
> > complete deprecation of unsafe hashers easier. 
>
> For testing, Django provides force_login(). This method skips password 
> hashing and logs a user in for a test. For tests that want a logged in 
> user and do not care about how the password was verified, this seems 
> like a good choice. Assuming this was used throughout, would this be 
> sufficient for handling this performance concern? 
>
> Tests that verify the password hasher will need to run the hash 
> algorithm regardless. 
>
>
> https://docs.djangoproject.com/en/1.9/topics/testing/tools/#django.test.Client.force_login
>  
>

-- 
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/38defa26-4380-4890-ba48-bbc822856a72%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: remove support for unsalted password hashers?

[Donald Stufft]

> 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/123D52C5-FE34-4B70-9D1D-8B5B702A405A%40stufft.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: remove support for unsalted password hashers?

[Tim Graham]

Just to be clear, my proposal here is only about removing 
UnsaltedSHA1PasswordHasher and UnsaltedMD5PasswordHasher. The salted 
versions of these hashers remain. I don't think the unsalted versions have 
any speed advantages as far as testing goes compared to the salted 
versions? Django's test settings use MD5PasswordHasher, not the unsalted 
version.

On Tuesday, February 2, 2016 at 12:23:50 PM UTC-5, Raphaël Barrois wrote:
>
> Hi Tim, 
>
> I would suggest removing those hashers from the default list, but keeping 
> at least the 
> django.contrib.auth.hashers.UnsaltedMD5PasswordHasher around. 
>
> That hasher, being the fastest non-plaintext hasher around, is quite 
> useful when running tests: it allows login checks 
> to be performed much faster. 
>
> Beyond this, the idea seems great — it's still pretty easy for a site to 
> keep them around if it needs them. 
>
>
> -- 
> Raphaël 
>
> On Tue, 2 Feb 2016 08:10:50 -0800 (PST) 
> Tim Graham  wrote: 
>
> > Django 0.90 stored passwords as unsalted MD5. Django 0.91 added support 
> for 
> > salted SHA1 with automatic upgrade of passwords [0]. 
> > 
> > In Django 1.4, the new password hashing machinery was added and some 
> users 
> > complained that they couldn't upgrade because the password format from 
> > Django 0.90 was no longer accepted (passwords encodings starting with 
> > "md5$$" or "sha1$$", though the ticket suggests Django never used the 
> > latter prefix) [1]. 
> > 
> > I wonder if it's about time to remove these hashers [2]? I think it'd be 
> > okay for users who haven't logged in since Django 0.90 to reset their 
> > password (assuming the site provides that mechanism). I would consider 
> > recommending that site administrators mark any unsalted passwords 
> > "unusable" to mitigate the possibility of leaking unsalted passwords in 
> the 
> > event the database is compromised. 
> > 
> > I think this is as simple as: 
> > 
> > users = User.objects.filter(password__startswith='md5$$') 
> > for user in users: 
> >  user.set_unusable_password() 
> >  user.save(update_fields=['password'] 
> > 
> > [0] https://code.djangoproject.com/ticket/18144#comment:18 
> > [1] https://code.djangoproject.com/ticket/18144 
> > [2] 
> > 
> https://github.com/django/django/compare/master...timgraham:remove-unsalted-hashers
>  
> > 
>
>

-- 
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/ff38c257-7218-446b-9de8-0d14d5f108f0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: remove support for unsalted password hashers?

[Jon Dufresne]

On Tue, Feb 2, 2016 at 10:35 AM, charettes  wrote:
>> That hasher, being the fastest non-plaintext hasher around, is quite
>> useful
>> when running tests: it allows login checks to be performed much faster.
>
> This argument came up a couple of time in the past and from what I remember
> the Django test suite itself spends a significant amount of time hashing
> passwords.
>
> I understand that we want to avoid shipping a plaintext password hasher in
> `django.contrib.auth.hashers` for the sake of not exposing a footgun-API but
> what if we shipped one in the `django.contrib.auth.test` package instead?
>
> We could document its use for testing purposes only and would make the
> complete deprecation of unsafe hashers easier.

For testing, Django provides force_login(). This method skips password
hashing and logs a user in for a test. For tests that want a logged in
user and do not care about how the password was verified, this seems
like a good choice. Assuming this was used throughout, would this be
sufficient for handling this performance concern?

Tests that verify the password hasher will need to run the hash
algorithm regardless.

https://docs.djangoproject.com/en/1.9/topics/testing/tools/#django.test.Client.force_login

-- 
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/CADhq2b5%3DnqrD2GOTTg4hjT4KxRUFGGT0tZZHCYypdggH-0ePqQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: remove support for unsalted password hashers?

[charettes]

> That hasher, being the fastest non-plaintext hasher around, is quite 
useful
> when running tests: it allows login checks to be performed much faster. 

This argument came up a couple of time in the past and from what I remember
the Django test suite itself spends a significant amount of time hashing
passwords.

I understand that we want to avoid shipping a plaintext password hasher in
`django.contrib.auth.hashers` for the sake of not exposing a footgun-API but
what if we shipped one in the `django.contrib.auth.test` package instead?

We could document its use for testing purposes only and would make the
complete deprecation of unsafe hashers easier.

Simon

Le mardi 2 février 2016 12:23:50 UTC-5, Raphaël Barrois a écrit :
>
> Hi Tim, 
>
> I would suggest removing those hashers from the default list, but keeping 
> at least the 
> django.contrib.auth.hashers.UnsaltedMD5PasswordHasher around. 
>
> That hasher, being the fastest non-plaintext hasher around, is quite 
> useful when running tests: it allows login checks 
> to be performed much faster. 
>
> Beyond this, the idea seems great — it's still pretty easy for a site to 
> keep them around if it needs them. 
>
>
> -- 
> Raphaël 
>
> On Tue, 2 Feb 2016 08:10:50 -0800 (PST) 
> Tim Graham  wrote: 
>
> > Django 0.90 stored passwords as unsalted MD5. Django 0.91 added support 
> for 
> > salted SHA1 with automatic upgrade of passwords [0]. 
> > 
> > In Django 1.4, the new password hashing machinery was added and some 
> users 
> > complained that they couldn't upgrade because the password format from 
> > Django 0.90 was no longer accepted (passwords encodings starting with 
> > "md5$$" or "sha1$$", though the ticket suggests Django never used the 
> > latter prefix) [1]. 
> > 
> > I wonder if it's about time to remove these hashers [2]? I think it'd be 
> > okay for users who haven't logged in since Django 0.90 to reset their 
> > password (assuming the site provides that mechanism). I would consider 
> > recommending that site administrators mark any unsalted passwords 
> > "unusable" to mitigate the possibility of leaking unsalted passwords in 
> the 
> > event the database is compromised. 
> > 
> > I think this is as simple as: 
> > 
> > users = User.objects.filter(password__startswith='md5$$') 
> > for user in users: 
> >  user.set_unusable_password() 
> >  user.save(update_fields=['password'] 
> > 
> > [0] https://code.djangoproject.com/ticket/18144#comment:18 
> > [1] https://code.djangoproject.com/ticket/18144 
> > [2] 
> > 
> https://github.com/django/django/compare/master...timgraham:remove-unsalted-hashers
>  
> > 
>
>

-- 
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/b24d4e9e-97d5-4d80-9afc-00b561c1b8bc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: remove support for unsalted password hashers?

[Raphaël Barrois]

Hi Tim,

I would suggest removing those hashers from the default list, but keeping at 
least the
django.contrib.auth.hashers.UnsaltedMD5PasswordHasher around.

That hasher, being the fastest non-plaintext hasher around, is quite useful 
when running tests: it allows login checks
to be performed much faster.

Beyond this, the idea seems great — it's still pretty easy for a site to keep 
them around if it needs them.


-- 
Raphaël

On Tue, 2 Feb 2016 08:10:50 -0800 (PST)
Tim Graham  wrote:

> Django 0.90 stored passwords as unsalted MD5. Django 0.91 added support for 
> salted SHA1 with automatic upgrade of passwords [0].
> 
> In Django 1.4, the new password hashing machinery was added and some users 
> complained that they couldn't upgrade because the password format from 
> Django 0.90 was no longer accepted (passwords encodings starting with 
> "md5$$" or "sha1$$", though the ticket suggests Django never used the 
> latter prefix) [1].
> 
> I wonder if it's about time to remove these hashers [2]? I think it'd be 
> okay for users who haven't logged in since Django 0.90 to reset their 
> password (assuming the site provides that mechanism). I would consider 
> recommending that site administrators mark any unsalted passwords 
> "unusable" to mitigate the possibility of leaking unsalted passwords in the 
> event the database is compromised.
> 
> I think this is as simple as:
> 
> users = User.objects.filter(password__startswith='md5$$')
> for user in users:
>  user.set_unusable_password()
>  user.save(update_fields=['password']
> 
> [0] https://code.djangoproject.com/ticket/18144#comment:18
> [1] https://code.djangoproject.com/ticket/18144
> [2] 
> https://github.com/django/django/compare/master...timgraham:remove-unsalted-hashers
> 

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

remove support for unsalted password hashers?

[Tim Graham]

Django 0.90 stored passwords as unsalted MD5. Django 0.91 added support for 
salted SHA1 with automatic upgrade of passwords [0].

In Django 1.4, the new password hashing machinery was added and some users 
complained that they couldn't upgrade because the password format from 
Django 0.90 was no longer accepted (passwords encodings starting with 
"md5$$" or "sha1$$", though the ticket suggests Django never used the 
latter prefix) [1].

I wonder if it's about time to remove these hashers [2]? I think it'd be 
okay for users who haven't logged in since Django 0.90 to reset their 
password (assuming the site provides that mechanism). I would consider 
recommending that site administrators mark any unsalted passwords 
"unusable" to mitigate the possibility of leaking unsalted passwords in the 
event the database is compromised.

I think this is as simple as:

users = User.objects.filter(password__startswith='md5$$')
for user in users:
 user.set_unusable_password()
 user.save(update_fields=['password']

[0] https://code.djangoproject.com/ticket/18144#comment:18
[1] https://code.djangoproject.com/ticket/18144
[2] 
https://github.com/django/django/compare/master...timgraham:remove-unsalted-hashers

-- 
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/57cc065d-8349-4c0a-a731-4091206f194b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.