#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 PaulM):

 I think the passhash stuff belongs in contrib.auth. It's specific enough
 to our use case that it would almost certainly require tweaking to work
 elsewhere. The upgrade mechanism, the specific string format - all of
 these are implementation details related to auth. It's a good system, but
 there's not a huge amount of stuff in it that reflects tricky (security-
 wise) implementation details.

 The PBKDF2 stuff belongs in utils.crypto.

 For better or worse the majority of the hashing code[1] IS crypto code.
 It's defined in [http://www.rsa.com/rsalabs/node.asp?id=2127 PKCS#5v2],
 and the implementation is designed primarily for deriving a key suitable
 for use in encryption. Our verification use case is an expected
 application of the spec, but is only a small part of what the code is
 intended to do.

 I'm not currently in favor of adding "encryption" type features to Django,
 but if we ever did, this code would be relevant for that use case. It
 would also be relevant for other signing-type operations, if we decide to
 extend the current functionality. Even if Django itself does not ever make
 use of this code for any purpose other than hashing user passwords, I
 would like it to be available to developers as an explicit crypto
 function, rather than requiring them to repurpose code that lives as part
 of auth.


 [1] Technically, this is key stretching, the "hashing" part is just the
 sha256 function.

 A more readable version of the relevant bits of spec can be found here:
 http://www.ietf.org/rfc/rfc2898.txt

-- 
Ticket URL: <https://code.djangoproject.com/ticket/15367#comment:15>
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.

Reply via email to