Thank you Luke.
On Sat, Jun 15, 2013 at 12:55 AM, Luke Plant <[email protected]> wrote: > The reason that SECRET_KEY is not used is that SECRET_KEY is used for > other applications which might require key cycling - typically for short > lived data where key cycling isn't going to cause too much of a problem. > > So if it was used as a salt for passwords, you would lose the ability to > check passwords when you cycled the key. > > That consideration doesn't stop you from using another value as a salt, > of course. > > If you are trying to get authentication to match an existing system, it > seems like a better approach would be to write a custom Django > authentication backend, rather than the other way around, especially if > you don't want to lose the security features of what you have already: > > > https://docs.djangoproject.com/en/1.5/topics/auth/customizing/#writing-an-authentication-backend > > >From reading the Django documentation, it appears I would need to create a custom password hasher that is identical to the default hasher, but passes (salt + settings.SECRET_KEY) to the pbkdf2() function instead of simply salt. This seems easy enough in principle. However, part of the appeal and motivation for porting the existing application to Django is moving away from the NIH of the existing application. Django gets so much of the foundation right. The existing application is currently implementing all this foundation itself; sometimes it does a good job, other times a poor job. I don't claim to be an expert on password encryption, so I would prefer to leave that sort of thing to the people that are smarter than me. This seems like I'd be losing a small portion of that value. I'd have to once again be implementing a piece of the password hasher. I guess I need to decide which way to go. Either a custom password hasher that uses a static salt, or use Django's existing password hasher and not think about it. Thanks for the help. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
