Using `SECRET_KEY` in password hashers

[Ram Rachum]

Hi,

What do you think about using the project's `SECRET_KEY` as an additional salt in Django's password hashers? The advantage would be that they'll be harder to crack, as an attacker would need access both to the database table and the code for the secret key. The disadvantage I can think of is that you couldn't change your `SECRET_KEY` without breaking old passwords (so maybe we need a separate secret in the settings.) 

What do you think? 

Thanks,

Ram.

[Curtis Maloney]

I think it'd royally screw you over if you ever had to change your secret key [due to suspected leak, for example] as now all your passwords are invalid.

--

Curtis

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/617aecb6-3156-49d1-859a-f55efb9f54f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ram Rachum]

Okay, so how about if we use a separate secret? 

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/fuJ5mbl8X5E/unsubscribe.
To unsubscribe from this group and all its topics, 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.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAG_XiSAS2o1EMSn5HQd-60Q2KutQ5uUUmYORQxsZeVM8rWbWpQ%40mail.gmail.com.

[Shai Berger]

On Tuesday 09 June 2015 08:23:03 Ram Rachum wrote:
> On Tue, Jun 9, 2015 at 8:22 AM, Curtis Maloney <cur...@acommoncreative.com>
> wrote:
> > On 9 June 2015 at 15:16, Ram Rachum <ram.r...@gmail.com> wrote:
> >>
> >> What do you think about using the project's `SECRET_KEY` as an
> >> additional salt in Django's password hashers?
>

> > I think it'd royally screw you over if you ever had to change your secret
> > key [due to suspected leak, for example] as now all your passwords are
> > invalid.
> >

> Okay, so how about if we use a separate secret?
>

How is it different? If you suspect a leak that forces you to change the secret
key, wouldn't you be forced to change this secret as well?

Shai.

[Ram Rachum]

If the leak happened because someone got into your code repo, you're right. (I can't rule out a scenario where someone got your SECRET_KEY with some other method, like analyzing data that was generated with the secret key.)

But even if there's a leak, then you're in a situation not worse than where we are today. Since you're still using a random salt in addition to the SECRET_KEY and you're using a hash function that takes non-negligible time. So best-case scenario, passwords become harder to crack, worst-case scenario, they're as hard to crack as they are with the current implementation. So isn't this an improvement?

[Curtis Maloney]

So, the benefit of your case is it's one more step for an attacker if they want to brute-force your password database -- that they _also_ need to steal your PASSWORD_SECRET.

The downside is, in the very case where they _do_ steal it, you must immediately invalidate every password by changing your PASSWORD_SECRET.  Which at least gives you a simple knob for doing just that, but may not be desirable.

IIRC you should be able to easily implement this as a custom password hasher...

--

C

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CANXboVavc8o3HZ%3DuP54PaD9CYgV25S8gPjBLfJhoBJSLSKtwKA%40mail.gmail.com.

[Ram Rachum]

On Tue, Jun 9, 2015 at 9:56 AM, Curtis Maloney <cur...@acommoncreative.com> wrote:

So, the benefit of your case is it's one more step for an attacker if they want to brute-force your password database -- that they _also_ need to steal your PASSWORD_SECRET.

The downside is, in the very case where they _do_ steal it, you must immediately invalidate every password by changing your PASSWORD_SECRET.  Which at least gives you a simple knob for doing just that, but may not be desirable.

"you must immediately invalidate": Well, you don't have to. If you don't, you still get the protection that you have with the password-specific hash, which is exactly what Django has today. In other words, when this system breaks, it becomes as secure as Django's current solution.

 

IIRC you should be able to easily implement this as a custom password hasher...

Yep, that's true.

 

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/fuJ5mbl8X5E/unsubscribe.
To unsubscribe from this group and all its topics, 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.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAG_XiSDFPjTX%3DwxXz%2BFc5wrwC02YCmy3w5JNobDpa9gk9wx1gw%40mail.gmail.com.

[Florian Apolloner]

FWIW the idea is relatively old and I think mozilla has a 3rd party app which just adds that functionality to the hashers. As far as I remember it even allows having multiple secrets and as such migrate to a new key.

[Josh Smeaton]

You're referring to a "pepper" - a site wide secret that's supposed to be used, in some way, to further encrypt passwords. As far as I'm aware there are no algorithms available that take a pepper into consideration. Further, I don't see the need for the inclusion of a pepper if the password encrypting function is solid. If we've selected the right algorithm and the right complexity (time and memory) then the time to brute force a single password is still going to be orders of magnitude out of reach.

http://blog.ircmaxell.com/2012/04/properly-salting-passwords-case-against.html

http://security.stackexchange.com/questions/41754/what-is-the-purpose-of-a-pepper

http://security.stackexchange.com/questions/3272/password-hashing-add-salt-pepper-or-is-salt-enough

[Aymeric Augustin]

Hello,

2015-06-09 16:16 GMT+02:00 Josh Smeaton <josh.s...@gmail.com>:

You're referring to a "pepper" - a site wide secret that's supposed to be used, in some way, to further encrypt passwords. As far as I'm aware there are no algorithms available that take a pepper into consideration.

I'm also wary of implementing a mechanism that isn't considered a best practice in the industry.

Pepper doesn't achieve anything that you couldn't do by changing the number of rounds (or perhaps the salt length, but I'm not sure that makes sense). Any additional code adds potential for implementation mistakes that could introduce security issues.

As a consequence, I think there are more risks than benefits to this proposal as it stands. I would change my mind if pepper countered a common class of attacks, like salt countered rainbow tables.

 

--

Aymeric.

[Fatih Erikli]

I recently created a ticket about it
https://code.djangoproject.com/ticket/34661

It has been marked duplicate of
https://code.djangoproject.com/ticket/30561

There is a document of NIST added on the original ticket.
I think if there is going to be any compliance investigation about a Django project, this will cause an issue.

Having salts on user tables causes different questions about the necessity of them, like if they are stored next to the password, why do we hash the password with a salt. There is so much work done already at that level. I think it should be a complete solution and should not leave any concern to the developers.

I don't want myself invent an authentication for my project. I don't want to use a patched or extended version of Django. Having a developer community consensus about the things we should concern, helps me to focus on the project. This is why I think we should have it in new Django projects by default.

[Fatih Erikli]

For those who need something like this, I created a python package "django-peppered-passwords".

https://github.com/fatih-erikli/django-peppered-passwords

--

You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/60f94770-ec26-4713-9b42-2b506a40fc68n%40googlegroups.com.