Re: remove support for unsalted password hashers?

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

Re: remove support for unsalted password hashers?

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,

Re: remove support for unsalted password hashers?

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

Re: remove support for unsalted password hashers?

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

Re: remove support for unsalted password hashers?

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

Re: remove support for unsalted password hashers?

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

Re: remove support for unsalted password hashers?

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

Re: remove support for unsalted password hashers?

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,

Re: remove support for unsalted password hashers?

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

Re: remove support for unsalted password hashers?

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

Re: remove support for unsalted password hashers?

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

Re: remove support for unsalted password hashers?

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

Re: remove support for unsalted password hashers?

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

Re: remove support for unsalted password hashers?

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

Re: remove support for unsalted password hashers?

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

Re: remove support for unsalted password hashers?

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

Re: remove support for unsalted password hashers?

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

Re: remove support for unsalted password hashers?

> 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

Re: remove support for unsalted password hashers?

> 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

Re: remove support for unsalted password hashers?

> 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

Re: remove support for unsalted password hashers?

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

Re: remove support for unsalted password hashers?

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

Re: remove support for unsalted password hashers?

> 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

Re: remove support for unsalted password hashers?

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

remove support for unsalted password hashers?

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