#15367: Improved Auth Password Hashing
-------------------------------------+-------------------------------------
Reporter: poswald | Owner: jart
Type: New | Status: new
feature | Component: contrib.auth
Milestone: 1.4 | Severity: Normal
Version: | Keywords: password, hash,
Resolution: | hashing, bcrypt, scrypt, pbkdf2,
Triage Stage: Accepted | sha2, sha1
Needs documentation: 1 | Has patch: 1
Patch needs improvement: 1 | Needs tests: 1
UI/UX: 0 | Easy pickings: 0
-------------------------------------+-------------------------------------
Comment (by jezdez):
Replying to [comment:8 jart]:
> Sorry I didn't notice the incorrect references to the old utils file; I
forgot to delete the pyc file :\
Hm, you seem to have put imports there now, please move the content of the
`passhash.py` file which was previously in the `utils.py` file back there
and the hasher classes to a file called `hashers.py` in the auth contrib
app's. The `utils.py` *is not deprecated* as you claim. The reason is
simple: there isn't any other password hashing happening outside the auth
contrib app, so it should live there, too.
> I uploaded a new patch with numerous changes including that backslash
thing. The change log is here: https://github.com/jart/django/commits
/auth-hashing
>
> You might be right that people should overload classes to change the
settings for a hasher so I included that in the new patch. We must
however keep the list because if people use a third party password hasher,
they need a way to migrate back to the standard ones. The only way to
avoid this is to not allow people to write their own custom hashers.
You misunderstood me, the setting would *not* be a list of hashers, but
just the module path of the activated hasher.
By default the `global_settings.py` should contain::
{{{
AUTH_PASSWORD_HASHER = 'django.contrib.auth.hashers.PBKDF2PasswordHasher'
}}}
and users can override that in their own `settings.py` accordingly (in
case they have any options to modify, which is unlikely):
{{{
AUTH_PASSWORD_HASHER = 'mysite.security.MyCustomBCryptPasswordHasher'
}}}
> I honestly think people should be discouraged from using the setting at
all. We put a lot of time and effort into making sure the default
behavior highly secure, stable, fast and portable without compromise. We
still need more tests, review and research, but I believe this PBKDF2
implementation will end up being an excellent choice for everybody.
Well, even if it's not a common case, those users that need to switch the
password algorithm (probably due to backwards compatibility or security
requirements) need some kind of documentation of how to do it. That
includes documenting the various hasher classes in that Django ships in
the `django.contrib.auth.hashers`.
--
Ticket URL: <https://code.djangoproject.com/ticket/15367#comment:9>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
