Looking at the code, the hard-coded salt seems OK to me. The encoding is
done by SessionBase.encode()
<https://github.com/django/django/blob/c58a8acd413ccc992dd30afd98ed900897e1f719/django/contrib/sessions/backends/base.py#L92>,
which calls dumps() from django.core.signing
<https://github.com/django/django/blob/c58a8acd413ccc992dd30afd98ed900897e1f719/django/core/signing.py#L131>.
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) <django-developers@googlegroups.com> 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 <s.lokesh1...@gmail.com>
> 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
>> <https://github.com/django/django/blob/main/django/contrib/sessions/backends/base.py#L64>.
>> 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
>> <https://groups.google.com/d/msgid/django-developers/6c6544b7-a190-4198-9108-6c66fac213ebn%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> 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
> <https://groups.google.com/d/msgid/django-developers/CAMyDDM1C6HxOVYrVL2XuBOhjWUb0EnThvzSAzocdKXrr%2BjkNEg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAJ3y2QS-CZEH_povK1e%3Dhm%2BdExGby0O_rWv8R9_rh5ZKiuUGHg%40mail.gmail.com.
