New Hashing Algorithm in Django 4.1

[iamsobanjaved]

Django introduced new signing algorithm sha256 as default in Django 3.1 and provided us the transitional settings to keep the algo same sha1 while upgrading to Django 3.1+. But now that transitional setting is removed in 4.0.

Now while testing on the sandbox, on upgrading the version of Django from 3.2 to 4.2 logged-in user is logged-out.

More from the release notes

The new DEFAULT_HASHING_ALGORITHM transitional setting allows specifying the default hashing algorithm to use for encoding cookies, password reset tokens in the admin site, user sessions, and signatures created by django.core.signing.Signer and django.core.signing.dumps().

Support for SHA-256 was added in Django 3.1. If you are upgrading multiple instances of the same project to Django 3.1, you should set DEFAULT_HASHING_ALGORITHM to 'sha1' during the transition, in order to allow compatibility with the older versions of Django. Note that this requires Django 3.1.1+. Once the transition to 3.1 is complete you can stop overriding DEFAULT_HASHING_ALGORITHM.

This setting is deprecated as of this release, because support for tokens, cookies, sessions, and signatures that use SHA-1 algorithm will be removed in Django 4.0.

https://docs.djangoproject.com/en/4.2/releases/3.1/#default-hashing-algorithm-settings

[awais786]

Related django PR django/django@d907371#diff-835852526356585f3ec8131d93e51e2617ba40f46018dce57a13764e5b23993c

[iamsobanjaved]

Related platform PR

• Adding fall back method for sha1 in case default algo is sha256 openedx/edx-platform#33345

[iamsobanjaved]

We updated the hashing algorithm to sha256 two weeks ago, and today only 1/3rd of the requests are going through the fallback path in LMS. This means these are the sessions that are still hashed from sha1 and if we upgrade to Django 4.2 today, these users will be logged out (don't know about the user count though, it is just based on requests).

From analyzing the code, found out that we set 4 week time of session expiry here, and as per my current knowledge we don't extend the session expiry time, hence the user will be logged out after 4 weeks even if he/she remains active in those 4 weeks.

Also currently we are blocked on MySQL upgrade for upgrading the Django version, and we are not aware of any exact timeline for when this blocker will be resolved, so we can wait for 2 more weeks so all old sessions will be logged out and replaced with new sessions. Also, the Django 4.2 upgrade PR is merged in the Quince branch, so waiting won't have any effect on the release schedule.

The question I currently have is whether my understanding of the session expiry is correct or if is there any Job/Middleware that extends the user's session expiry.

@robrap

[robrap]

@iamsobanjaved

The question I currently have is whether my understanding of the session expiry is correct or if is there any Job/Middleware that extends the user's session expiry.

I would have guessed that the graphs would show more of an increase in 'default' and drop in 'fallback' than they do. Is it possible that each time the fallback happens it gets extended as a 'fallback' session, rather than immediately replacing it a 'default' session?

Also, I added an (estimated) user count for fallbacks to the dashboard.

[iamsobanjaved]

Missed the notification. The current update is that all users are now shifted to the new hashing algorithm in prod, but for Edge, there are still around 25-30% of users with the old hashing algorithm. We tried comparing configs of prod and edge to find out why the users are not being logged out there after 4 weeks. We found one user who logged in around 2.5 months ago and was still not logged out. @robrap Any idea what could be the reason for that?

[robrap]

Sorry @iamsobanjaved. I do not know. I didn't see any obvious config differences, but I'm not sure of session length. If you log in to prod and edge in a private browser, is there an obvious difference in the session cookie expiration?

Separately, once you've established you won't cause a storm of logins that could hurt the system, you could always decide to update and force re-logins.