Re: Why using django.contrib.sessions as the salt to encode session data? why not secret key?

2022-10-12 Thread James Bennett 
On Wed, Oct 12, 2022 at 3:25 PM 'Adam Johnson' via Django developers
(Contributions to Django itself)  wrote:

> Thank you for diving into this John! All seems sensible then.
>
Yeah, the threat model here is you have, say, Endpoints A and B that each
work with HMAC'd values, and Endpoint A generates them based at least in
part on user input. With some cleverness, an attacker might figure out how
to get Endpoint A to generate an HMAC that Endpoint B will accept as valid.

Now, imagine that Endpoint B is, say, password reset.

This is why uses of HMAC should be namespaced. It's maybe unfortunate that
the exact keyword argument is named "salt" when people are used to that
being a unique-per-call random value rather than a constant, but a constant
is the expected pattern for many usages of HMAC in Django and in Django
apps.

-- 
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/CAL13Cg-vH4Otf6QWDnHpeYbufsDQfWfxhJ-1TF%3DS_iBk8CL%2BVw%40mail.gmail.com.

Re: Why using django.contrib.sessions as the salt to encode session data? why not secret key?

2022-10-12 Thread 'Adam Johnson' via Django developers (Contributions to Django itself) 
Thank you for diving into this John! All seems sensible then.

On Wed, Oct 5, 2022 at 11:53 PM 'John Whitlock' via Django developers
(Contributions to Django itself)  wrote:

> Looking at the code, the hard-coded salt seems OK to me. The encoding is
> done by SessionBase.encode()
> ,
> which calls dumps() from django.core.signing
> .
> The docstring says:
>
>
>
>
>
>
> *Return URL-safe, hmac signed base64 compressed JSON string. If key is
> None, use settings.SECRET_KEY instead. The hmac algorithm is the default
> Signer algorithm.If compress is True (not the default), check if
> compressing using zlib can save some space. Prepend a '.' to signify
> compression. This is included in the signature, to protect against zip
> bombs.Salt can be used to namespace the hash, so that a signed string is
> only valid for a given namespace. Leaving this at the default value or
> re-using a salt value across different parts of your application without
> good cause is a security risk.*
>
> *The serializer is expected to return a bytestring.*
>
> So, settings.SECRET_KEY is used to sign the session, and salt acts like a
> namespace to distinguish sessions from other uses of the SECRET_KEY.
>
> Trying it out in `./manage.py shell`:
>
> >>> from django.contrib.sessions.backends.db import SessionStore
> >>> from django.core.signing import b64_decode
> >>> session = SessionStore().encode({"foo": "bar"})
> >>> print(session)
> eyJmb28iOiJiYXIifQ:1ogD1v:OIpRWKZdxbhox3d7XaS7A0bZouEXQV6jx03FlAaDGZo
> >>> val, ts, sign = session.split(':')
> SessionStore().encode({"foo": "bar"})
> >>> b64_decode(val.encode())
> b'{"foo":"bar"}'
> >>> b64_decode(ts.encode())
> b'\xd6\x88\x03\xd6'
> >>> b64_decode(sign.encode())
>
> b'8\x8aQX\xa6]\xc5\xb8h\xc7w{]\xa4\xbb\x03F\xd9\xa2\xe1\x17A^\xa3\xc7M\xc5\x94\x06\x83\x19\x9a'
> >>> len(b64_decode(z.encode()))
> 32
>
> The first section of the session value is the encoded value, base64
> encoded, and potentially compressed.
> The second section is the encoded timestamp, used to determine if it was
> created too long ago on decode
> The third section is the HMAC signature, base64 encoded.
>
> - John
>
> On Wed, Oct 5, 2022 at 4:45 PM 'Adam Johnson' via Django developers
> (Contributions to Django itself) 
> wrote:
>
>> Looking through blame, it looks like this hardcoded salt was added in
>> 2010:
>> https://github.com/django/django/commit/45c7f427ce830dd1b2f636fb9c244fda9201cadb#diff-3a6c11bbe36a0e6927f71ad8d669f0021897ba73768ee41073a318a12e11c3d1L85-L90
>>
>> This actually changed from using the secret key as the salt, to the fixed
>> string, whilst also changing the algorithm from MAC to HMAC. But I cannot
>> see any discussion on why in the ticket:
>> https://code.djangoproject.com/ticket/14445 .
>>
>> 路‍♂️
>>
>> On Mon, Oct 3, 2022 at 8:43 AM Lokesh Sanapalli 
>> wrote:
>>
>>> Hi,
>>>
>>> I was going through the code and got a question. I saw that we are
>>> using hard-coded string `django.contrib.sessions` as the key salt to encode
>>> session data
>>> .
>>> Why not using the secret key? as the secret key is specific to environment
>>> and project it serves as a good candidate. Is it because the session data
>>> does not contain any sensitive info (it only contains user id and other
>>> info) so that's why this decision is made?
>>>
>>> Thanks & Regards,
>>> Lokesh Sanpalli
>>>
>>> --
>>> 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/6c6544b7-a190-4198-9108-6c66fac213ebn%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/CAMyDDM1C6HxOVYrVL2XuBOhjWUb0EnThvzSAzocdKXrr%2BjkNEg%40mail.gmail.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers

Re: Model-level validation

2022-10-12 Thread Aaron Smith 
I think the core developers who are making assertions about what is 
"accessible" and "makes sense" to newcomers would be well served by taking 
into account the actual experiences of newcomers. The expectation does not 
appear to align with reality.

On Wednesday, October 12, 2022 at 1:19:56 AM UTC-7 jure.er...@gmail.com 
wrote:

> I'd like to chime in with this:
>
> There was a point in time when we ran into this issue and solved it with 
> our own Model descendant.
>
> IMHO, I'm completely with Aaron on this: all the guts are there, just not 
> being used. It took me quite a while to wrap my brain around the idea that 
> validation would be specified in models, but only used in forms. And then 
> some more looking at why all the support functions are in models, but not 
> being used. It just didn't compute why I would have validation when using 
> Django one way, but not when I wanted something a little different.
>
> While all the arguments against providing this function are valid and 
> good, they neglect that an implementation satisfying n00bs like me would 
> really not carry any penalties: it's just an if in the model.save checking 
> against a global setting. No code creep, no additional tests to write (but 
> I'm pretty sure some of the existing ones might fail, django or end-app). 
> It would remove some confusion, but grandmasters like yourselves could 
> still turn it off and do it the way you believe is "the correct one".
>
> Also, just to be clear: the above solution (turning this on) yielded TONS 
> of bugs when we did it for our projects. We vastly improved unit testing 
> following this implementation, so it was a total win for us.
>
> LP,
> Jure
> On 9. 10. 22 08:58, James Bennett wrote:
>
> On Sat, Oct 8, 2022 at 8:32 PM Aaron Smith  wrote:
>
>> Surely we can agree that *something* should happen here? The status quo 
>>> is confusing, a footgun and a gotcha. If it's not Model's concern, then get 
>>> it out of Model.
>>>
>>
> I've already said that I wish model-level validation hadn't been added to 
> Django.
>
> Unfortunately it's something that's been in long enough now that it would 
> be very difficult to deprecate and remove. But that's not an argument, to 
> my mind, for expanding it.
>
> -- 
> 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/CAL13Cg8ZvG6%3DtCNEEKV-4rQURzZ_GFSuPRypkoOOqGULFC9pZw%40mail.gmail.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/f51c389c-ad1c-430a-8029-c9fef489ed00n%40googlegroups.com.

Re: Proposal: cacheif template tag

2022-10-12 Thread Igor Margitich 
Hey Carlton,
I am not sure I got your idea.
The point of proposal is not in user.is_authenticated. 
user.is_authenticated is just a boolean. Conditional caching for non logged 
in user is just very simple and common use case when `cacheif` could be 
used. 

пʼятниця, 30 вересня 2022 р. о 09:09:53 UTC+2 carlton...@gmail.com пише:

> Hey Igor, 
>
> I wonder if you can achieve the same varying the timeout parameter based 
> in user.is_authenticated?
>
> Kind Regards,
>
> Carlton
>
> On Sat, 24 Sept 2022 at 15:35, Igor Margitich  wrote:
>
>> Hi django-developers,
>>
>> I would like to propose new template tag `cacheif`. Could be useful when 
>> you need to cache part of html and it depends on some condition. Template 
>> tag is similar to built-in `cache` tag but accepts extra boolean parameter. 
>> See example:
>>
>> {% cacheif user.is_anonymous 10 homepage %}
>>   
>>  .
>>   
>> {% endcacheif %}
>>
>>
>> -- 
>> 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/bcf8ffee-6497-4a55-ba40-913446d15b06n%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/a44ef6f2-b546-4f16-96ff-3055b9910961n%40googlegroups.com.

Re: Model-level validation

2022-10-12 Thread Jure Erznožnik 

I'd like to chime in with this:

There was a point in time when we ran into this issue and solved it with 
our own Model descendant.


IMHO, I'm completely with Aaron on this: all the guts are there, just 
not being used. It took me quite a while to wrap my brain around the 
idea that validation would be specified in models, but only used in 
forms. And then some more looking at why all the support functions are 
in models, but not being used. It just didn't compute why I would have 
validation when using Django one way, but not when I wanted something a 
little different.


While all the arguments against providing this function are valid and 
good, they neglect that an implementation satisfying n00bs like me would 
really not carry any penalties: it's just an if in the model.save 
checking against a global setting. No code creep, no additional tests to 
write (but I'm pretty sure some of the existing ones might fail, django 
or end-app). It would remove some confusion, but grandmasters like 
yourselves could still turn it off and do it the way you believe is "the 
correct one".


Also, just to be clear: the above solution (turning this on) yielded 
TONS of bugs when we did it for our projects. We vastly improved unit 
testing following this implementation, so it was a total win for us.


LP,
Jure

On 9. 10. 22 08:58, James Bennett wrote:

On Sat, Oct 8, 2022 at 8:32 PM Aaron Smith  wrote:

Surely we can agree that /something/ should happen here? The
status quo is confusing, a footgun and a gotcha. If it's not
Model's concern, then get it out of Model.


I've already said that I wish model-level validation hadn't been added 
to Django.


Unfortunately it's something that's been in long enough now that it 
would be very difficult to deprecate and remove. But that's not an 
argument, to my mind, for expanding it.

--
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/CAL13Cg8ZvG6%3DtCNEEKV-4rQURzZ_GFSuPRypkoOOqGULFC9pZw%40mail.gmail.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/5ee186ae-f22e-9a4e-c8e9-c0b353f1762b%40gmail.com.