remove support for unsalted password hashers?
419 views
Skip to first unread message
Tim Graham
Feb 2, 2016, 11:10:50 AM2/2/16
to Django developers (Contributions to Django itself)
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
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
Raphaël Barrois
Feb 2, 2016, 12:23:50 PM2/2/16
to Django developers (Contributions to Django itself)
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
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
charettes
Feb 2, 2016, 1:35:23 PM2/2/16
to Django developers (Contributions to Django itself)
> That hasher, being the fastest non-plaintext hasher around, is quite useful
> when running tests: it allows login checks to be performed much faster.
> 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
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
Jon Dufresne
Feb 2, 2016, 1:49:31 PM2/2/16
to django-d...@googlegroups.com
On Tue, Feb 2, 2016 at 10:35 AM, charettes <chare...@gmail.com> 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
>> 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.
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
Tim Graham
Feb 2, 2016, 1:52:26 PM2/2/16
to Django developers (Contributions to Django itself)
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.
Donald Stufft
Feb 2, 2016, 2:20:44 PM2/2/16
to django-d...@googlegroups.com
On Feb 2, 2016, at 1:52 PM, Tim Graham <timog...@gmail.com> 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
-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
charettes
Feb 2, 2016, 2:52:10 PM2/2/16
to Django developers (Contributions to Django itself)
> 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?
> 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.
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.
charettes
Feb 2, 2016, 2:52:33 PM2/2/16
to Django developers (Contributions to Django itself)
> 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?
> 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.
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.
> 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 :
Le mardi 2 février 2016 13:49:31 UTC-5, Jon Dufresne a écrit :
Tim Graham
Feb 3, 2016, 3:26:01 PM2/3/16
to Django developers (Contributions to Django itself)
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" .
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" .
Raphaël Barrois
Feb 4, 2016, 12:22:09 PM2/4/16
to Django developers (Contributions to Django itself)
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 <timog...@gmail.com> 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 <timog...@gmail.com <javascript:>>
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 <timog...@gmail.com> 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:
> >
> >
Florian Apolloner
Feb 4, 2016, 12:47:44 PM2/4/16
to Django developers (Contributions to Django itself)
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
Tim Graham
Feb 4, 2016, 7:43:14 PM2/4/16
to Django developers (Contributions to Django itself)
I wasn't sure how to upgrade passwords as Florian said. Here's the answer from Donald in IRC:
You can always wrap hashers, e.g. if you have a hasher which is sha1(password), add a new hasher which is bcrypt(sha1(password))
You can convert your database in a migration and you immediately get all the benefits of a better hash.
--
Florian, I wonder if you could share your upgrade script so we could use it as a template in the release notes?
You can always wrap hashers, e.g. if you have a hasher which is sha1(password), add a new hasher which is bcrypt(sha1(password))
You can convert your database in a migration and you immediately get all the benefits of a better hash.
--
Florian, I wonder if you could share your upgrade script so we could use it as a template in the release notes?
Rafał Pitoń
Feb 5, 2016, 7:05:01 AM2/5/16
to Django developers (Contributions to Django itself)
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 (>1000000 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?
Donald Stufft
Feb 5, 2016, 9:38:23 AM2/5/16
to django-d...@googlegroups.com
>
> On Feb 5, 2016, at 7:05 AM, Rafał Pitoń <rafio...@gmail.com> 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 (>1000000 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.
> On Feb 5, 2016, at 7:05 AM, Rafał Pitoń <rafio...@gmail.com> 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 (>1000000 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 also do bcrypt(md5(md5(pass) + md5(pass)) and then you’ve fixed the issue without needing to issue a password reset.
Tim Graham
Feb 5, 2016, 10:04:12 AM2/5/16
to Django developers (Contributions to Django itself)
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.
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.
Donald Stufft
Feb 5, 2016, 10:05:31 AM2/5/16
to django-d...@googlegroups.com
> On Feb 5, 2016, at 10:04 AM, Tim Graham <timog...@gmail.com> 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.
Tim Graham
Feb 5, 2016, 10:40:27 AM2/5/16
to Django developers (Contributions to Django itself)
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").
Sergei Maertens
Feb 5, 2016, 3:11:20 PM2/5/16
to Django developers (Contributions to Django itself)
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.
Aymeric Augustin
Feb 5, 2016, 3:20:41 PM2/5/16
to django-d...@googlegroups.com
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.
--
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.
Tim Graham
Feb 5, 2016, 6:03:48 PM2/5/16
to Django developers (Contributions to Django itself)
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?
Aymeric Augustin
Feb 6, 2016, 3:51:37 AM2/6/16
to django-d...@googlegroups.com
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/9e184cd6-69cc-4fe8-835e-055bc7121ac9%40googlegroups.com.
Curtis Maloney
Feb 6, 2016, 3:56:00 AM2/6/16
to django-d...@googlegroups.com
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 <timog...@gmail.com
>>> <https://groups.google.com/group/django-developers>.
>> <mailto:django-d...@googlegroups.com>.
>> <https://groups.google.com/d/msgid/django-developers/9e184cd6-69cc-4fe8-835e-055bc7121ac9%40googlegroups.com?utm_medium=email&utm_source=footer>.
> <https://groups.google.com/d/msgid/django-developers/5081977A-64B0-4443-ADDE-CEFCC5704E72%40polytechnique.org?utm_medium=email&utm_source=footer>.
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 <timog...@gmail.com
>> <mailto:timog...@gmail.com>> 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
>>
>> 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
>>> <javascript:>> 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
>>> (>1000000 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 <javascript:>.
>>>
>>> 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
>>> (>1000000 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,
>>> To post to this group, send email to django-d...@googlegroups.com
>>> <javascript:>.
>>> <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&utm_source=footer>.
>>> 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
>>> <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
>> <mailto:django-develop...@googlegroups.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-develop...@googlegroups.com
>> <mailto: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/9e184cd6-69cc-4fe8-835e-055bc7121ac9%40googlegroups.com
>> To view this discussion on the web visit
>> <https://groups.google.com/d/msgid/django-developers/9e184cd6-69cc-4fe8-835e-055bc7121ac9%40googlegroups.com?utm_medium=email&utm_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
> <mailto:django-develop...@googlegroups.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-develop...@googlegroups.com
> To post to this group, send email to django-d...@googlegroups.com
> <mailto: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/5081977A-64B0-4443-ADDE-CEFCC5704E72%40polytechnique.org
> To view this discussion on the web visit
> <https://groups.google.com/d/msgid/django-developers/5081977A-64B0-4443-ADDE-CEFCC5704E72%40polytechnique.org?utm_medium=email&utm_source=footer>.
Tim Graham
Feb 8, 2016, 3:12:28 PM2/8/16
to Django developers (Contributions to Django itself)
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
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
>> <mailto:django-developers+unsub...@googlegroups.com>.
>> To post to this group, send email to
>> django-d...@googlegroups.com
>> <mailto: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/9e184cd6-69cc-4fe8-835e-055bc7121ac9%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/9e184cd6-69cc-4fe8-835e-055bc7121ac9%40googlegroups.com?utm_medium=email&utm_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
> <mailto:django-developers+unsub...@googlegroups.com>.
Tim Graham
Feb 10, 2016, 5:16:11 PM2/10/16
to Django developers (Contributions to Django itself)
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
[1] https://github.com/django/django/pull/6114
Tim Graham
Feb 17, 2016, 1:24:04 PM2/17/16
to Django developers (Contributions to Django itself)
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
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
Tim Graham
Feb 18, 2016, 11:52:53 AM2/18/16
to Django developers (Contributions to Django itself)
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.
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.
Markus Holtermann
Feb 22, 2016, 6:31:31 PM2/22/16
to Django developers (Contributions to Django itself)
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
Reply all
Reply to author
Forward
0 new messages