Question about password salt and encryption

[jon.du...@gmail.com]

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.

[Luke Plant]

Hi Jon,

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/

[Jon Dufresne]

Thank you Luke.

On Sat, Jun 15, 2013 at 12:55 AM, Luke Plant <L.Pla...@cantab.net> 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.

[Aymeric Augustin]

On 15 juin 2013, at 15:17, Jon Dufresne <jon.du...@gmail.com> wrote:

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.

The first option is a very thin addition on top of Django's authentication framework. Many parts of Django are pluggable precisely to allow such customizations. I view it as standing on the shoulders of giants rather than NIH.

To make the migration easier, you'll probably put your current salt value in a setting distinct from SECRET_KEY.

-- 

Aymeric.

[Luke Plant]

On 15/06/13 14:17, Jon Dufresne wrote:

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

There are two questions here:

1) What should you do for your system?

2) Should Django's security be improved by an additional salt that isn't
stored in the database?

Regarding number 2, this is not likely to happen quickly, due to
backwards compatibility issues, and the need to introduce a new setting
etc. (That may help you to decide question 1).

It's definitely worth considering, of course. We would have to consider
whether it is worth the work. For many installations, if an attacker has
the database they are very likely to have the source code too. Of
course, we should try to layer security so that it isn't all or nothing.
But given the difficulties of changing things, we'd have to consider
whether the increase in security, in a typical setup, would justify the
change.

[Donald Stufft]

--
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 django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Backwards compatibility is easy. Just add a new hasher.

-----------------

Donald Stufft

PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

[Jon Dufresne]

On Sat, Jun 15, 2013 at 2:24 PM, Luke Plant <L.Pla...@cantab.net> wrote:

2) Should Django's security be improved by an additional salt that isn't
stored in the database?

Regarding number 2, this is not likely to happen quickly, due to
backwards compatibility issues, and the need to introduce a new setting
etc. (That may help you to decide question 1).

It's definitely worth considering, of course. We would have to consider
whether it is worth the work. For many installations, if an attacker has
the database they are very likely to have the source code too. Of
course, we should try to layer security so that it isn't all or nothing.
But given the difficulties of changing things, we'd have to consider
whether the increase in security, in a typical setup, would justify the
change.

Are you suggesting this should be a change to Django itself? A new password hasher that uses a per user salt as well as a static salt stored outside the database? Should I file this as a ticket or is this just hypothetical?