#9101 closed (wontfix)
Improved salt generation for django.contrib.auth
Reported by: | Ludvig Ericson | Owned by: | nobody |
---|---|---|---|
Component: | contrib.auth | Version: | dev |
Severity: | Keywords: | ||
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Currently, the salts generated by the auth framework are pretty weak.
This patch changes the behavior of doing a SHA1 hash of digits into choosing five random characters from the lower and upper alphabet, as well as any digit. [a-zA-Z0-9]
See the django-dev this: http://tinyurl.com/5tjvhc
Attachments (2)
Change History (9)
by , 16 years ago
Attachment: | django-salts.diff added |
---|
comment:1 by , 16 years ago
milestone: | → 1.1 |
---|---|
Triage Stage: | Unreviewed → Accepted |
comment:2 by , 16 years ago
comment:4 by , 16 years ago
Regarding the latest patch, why import the name each time the function is run? I mean no, it's probably not going to be noticeable WRT the function's purpose, but I'm curious.
comment:5 by , 16 years ago
I was just following the example of the existing code, which imported the module inside the function. Elsewhere in the same module there's a similar import of random within another function, so I assumed there was some benefit to delaying the import until it's needed, since Django does this in many places.
I personally don't do late imports, but this style seemed to fit the module better. But really, it probably doesn't matter either way.
comment:6 by , 16 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
This really isn't a change with any value; salt doesn't need to be particularly cryptographically strong as long as it's random enough; the point is to exponentially increase the search space for password crackers. The current code is fine.
You can also add string.punctuation to the SALT_CHARS soup.