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 On 9 June 2015 at 16:01, Ram Rachum <r...@rachum.com> wrote: > 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? > > On Tue, Jun 9, 2015 at 8:55 AM, Shai Berger <s...@platonix.com> wrote: > >> 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.rac...@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. >> > > -- > 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-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@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 > <https://groups.google.com/d/msgid/django-developers/CANXboVavc8o3HZ%3DuP54PaD9CYgV25S8gPjBLfJhoBJSLSKtwKA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@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. For more options, visit https://groups.google.com/d/optout.
