Offer the ability to store a hash of session IDs rather than the ID itself

[Tim Graham]

We should offer the ability to store a hash each session ID in the session backend rather the the ID itself. This hash should be reasonably fast, because it'll be re-computed for every request. Currently, if an attacker gains access to the session storage backend — which may easier than gaining access to the database — he can login as anyone on the site.

On a related note, we're inconsistent about whether or not we sign entries in the session backends. Some do, some don't. If we're hashing session keys by default, we should probably also sign everything by default.

Both of these things need an off-switch. There are a fair number of apps that rely on raw sessionids to provide cross-framework compatibility.

[Chris Griffin]

​PR

[Carlton Gibson]

Aymeric reviewed this on the PR, leaving suggestions for improvement. Once those are (roughly) addressed please uncheck Patch needs improvement and we can have another look.

[Mark]

Picking this up together with #31412

[Mark]

Requesting feedback about naming convention (see ​this PR comment) to make a clear distinction between incoming "clear text" session keys and session keys that are stored in the sessions backend (potentially hashed, but not necessarily, depending on settings and existing session keys). My suggestion is to use the names frontend_key and backend_key respectively.

Also requesting feedback concerning a refactor of the SessionBase API to DRY-up the session key conversion (see ​this PR comment).

[Mark]

New PR: ​https://github.com/django/django/pull/12814

Though the patch surely does still need improvement (documentation at the very least),
I'm removing the 'Patch needs improvement' flag to get some feedback on the current implementation.