Hi Jon,

> I am in the process of porting an existing application to use Django. I
> am modifying the authentication portion of the existing application to
> be compatible with Django's authentication system. One thing that struck
> me, Django appears to use a single per user salt, stored in the
> database. However, the existing application uses two salts, one static
> salt stored outside the database, and a per user salt stored in the
> database. From all the advice I've received about secure authentication
> it seems the two salt method is standard behavior and considered a best
> practice. Is there a reason Django does not use the SECRET_KEY (or some
> other static salt) when encrypting passwords? Is this still considered a
> secure encryption mechanism? This feels like a step backwards for the
> authentication of this application.

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

Regards,

Luke

-- 
"Pessimism: Every dark cloud has a silver lining, but lightning
kills hundreds of people each year trying to find it." (despair.com)

Luke Plant || http://lukeplant.me.uk/

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


Reply via email to