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
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 wher
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 i
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 20
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
> s
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 i
> On 8 juin 2015, at 15:25, Tim Graham wrote:
>
> Any other feedback on the proposal? I could assume no complaints is a good
> sign, but some +1's would be easier to interpret. :-)
I think your proposal is a reasonable compromise. It came up briefly during
some discussions among core devs at D
> On 8 juin 2015, at 15:24, Marten Kenbeek wrote:
>
> If there is a consensus that thread-local storage is the better solution
I don’t think there’s consensus when only one person brought up the idea :-)
I’m unconvinced at this time and I’ll probably argue against it if it gets more
seriously
Hi all,
After lots of great work by Trey Hunner on the draft implementation (and
review from Tim Graham, Aymeric Augustin, Tomasz Paczkowski, and James
Da Costa), I think DEP 3 is ready for acceptance.
The latest draft of the DEP is here:
https://github.com/django/deps/blob/master/draft/0003-java
On 06/07/2015 02:18 AM, Shai Berger wrote:
> Semi-devil's-advocate suggestion: Replace the management form with a
> management field, a hidden field with
>
> name = "__manage__%s" % (formsetname)
>
> and
>
> value="x"
>
> Then instead of taking the number of forms from a field o
On 06/08/2015 04:11 AM, Patryk Zawadzki wrote:
> 2015-06-07 10:18 GMT+02:00 Shai Berger :
>> Semi-devil's-advocate suggestion: Replace the management form with a
>> management field, a hidden field with
>>
>> name = "__manage__%s" % (formsetname)
>>
>> and
>>
>> value="x"
>>
>> Then
+1 dude!! go for it!
On Mon, Jun 8, 2015 at 7:25 PM, Tim Graham wrote:
> Any other feedback on the proposal? I could assume no complaints is a good
> sign, but some +1's would be easier to interpret. :-)
>
>
> On Monday, June 1, 2015 at 11:09:12 AM UTC-4, Collin Anderson wrote:
>>
>> I see. I mi
Any other feedback on the proposal? I could assume no complaints is a good
sign, but some +1's would be easier to interpret. :-)
On Monday, June 1, 2015 at 11:09:12 AM UTC-4, Collin Anderson wrote:
>
> I see. I missed the "first upgrade Django to the last release before the
> next
> LTS (e.g. u
I actually don't think this behaviour should extend to reverse(). There are
good reasons to use request.current_app in the template, but I don't
believe this implicit behaviour is warranted outside the templates. Not
everyone might agree, but I also believe that get_absolute_url() should
return
2015-06-07 10:18 GMT+02:00 Shai Berger :
> Semi-devil's-advocate suggestion: Replace the management form with a
> management field, a hidden field with
>
> name = "__manage__%s" % (formsetname)
>
> and
>
> value="x"
>
> Then instead of taking the number of forms from a field on a ma
15 matches
Mail list logo
