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) <django-developers@googlegroups.com> wrote:
> 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 > <https://groups.google.com/d/msgid/django-developers/CAJ3y2QS-CZEH_povK1e%3Dhm%2BdExGby0O_rWv8R9_rh5ZKiuUGHg%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/CAMyDDM2j-mC64vyvxSe_6ieHd00xe12xsUVooBCikbRh%2BDXZwA%40mail.gmail.com.
