Re: Using `SECRET_KEY` in password hashers

[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

On Mon, Jun 19, 2023 at 8:54 PM Fatih Erikli 
wrote:

> 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.
>
> On Tuesday, June 9, 2015 at 5:31:48 PM UTC+3 Aymeric Augustin wrote:
>
>> Hello,
>>
>> 2015-06-09 16:16 GMT+02:00 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.
>>>
>>
>> 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.
>>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/60f94770-ec26-4713-9b42-2b506a40fc68n%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CA%2B7drOEM3r0vBy2q4%3DfkkLw1fqCP5c8%2BW5EHYpVbUk1eLwumnA%40mail.gmail.com.

Re: Using `SECRET_KEY` in password hashers

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

On Tuesday, June 9, 2015 at 5:31:48 PM UTC+3 Aymeric Augustin wrote:

> Hello,
>
> 2015-06-09 16:16 GMT+02:00 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.
>>
>
> 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.
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/60f94770-ec26-4713-9b42-2b506a40fc68n%40googlegroups.com.

Re: Using `SECRET_KEY` in password hashers

[Aymeric Augustin]

Hello,

2015-06-09 16:16 GMT+02:00 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.
>

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.

-- 
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/CANE-7mWkSMxN_9xqGXchC8O-onxJZ36AxuSRbsDXF%3DxThUrs3Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using `SECRET_KEY` in password hashers

[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


On Tuesday, 9 June 2015 15:16:02 UTC+10, Ram Rachum wrote:
>
> 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.
>

-- 
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/c1ec72af-6840-41d6-9c7b-9632baaa5aa0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using `SECRET_KEY` in password hashers

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

On Tuesday, June 9, 2015 at 7:16:02 AM UTC+2, Ram Rachum wrote:
>
> 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.
>

-- 
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/1fb3fcb0-861f-40d9-a111-d974f612ab3e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using `SECRET_KEY` in password hashers

[Ram Rachum]

On Tue, Jun 9, 2015 at 9:56 AM, Curtis Maloney 
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.


>
> --
> C
>
>
> On 9 June 2015 at 16:01, Ram Rachum  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  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  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
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> 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-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.
>

-- 
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/CANXboVaawF%2BYm8h3CBrU7EY29XS__d2QJoqrjhYAO5dzYoxKKg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using `SECRET_KEY` in password hashers

[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


On 9 June 2015 at 16:01, Ram Rachum  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  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  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
> 
> .
>
> 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.

Re: Using `SECRET_KEY` in password hashers

[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?

On Tue, Jun 9, 2015 at 8:55 AM, Shai Berger  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  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.
For more options, visit https://groups.google.com/d/optout.

Re: Using `SECRET_KEY` in password hashers

[Shai Berger]

On Tuesday 09 June 2015 08:23:03 Ram Rachum wrote:
> On Tue, Jun 9, 2015 at 8:22 AM, Curtis Maloney 
> wrote:
> > On 9 June 2015 at 15:16, Ram Rachum  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.

Re: Using `SECRET_KEY` in password hashers

[Ram Rachum]

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

On Tue, Jun 9, 2015 at 8:22 AM, Curtis Maloney 
wrote:

> 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
>
>
> On 9 June 2015 at 15:16, Ram Rachum  wrote:
>
>> 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.
>>
>> --
>> 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/617aecb6-3156-49d1-859a-f55efb9f54f2%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> 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-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_XiSAS2o1EMSn5HQd-60Q2KutQ5uUUmYORQxsZeVM8rWbWpQ%40mail.gmail.com
> 
> .
>
> 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/CANXboVYME4BKs-vQwyV3i-P4CqfX8juLtMwKuNeuss5pFELM1g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using `SECRET_KEY` in password hashers

[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


On 9 June 2015 at 15:16, Ram Rachum  wrote:

> 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.
>
> --
> 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/617aecb6-3156-49d1-859a-f55efb9f54f2%40googlegroups.com
> 
> .
> 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_XiSAS2o1EMSn5HQd-60Q2KutQ5uUUmYORQxsZeVM8rWbWpQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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.

-- 
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/617aecb6-3156-49d1-859a-f55efb9f54f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.