id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
33806	The `salt` argument for signing functions should not be optional.	Luke Plant	nobody	"The docs currently have a reasonable explanation of why the `salt` argument is needed: https://docs.djangoproject.com/en/4.0/topics/signing/#using-the-salt-argument

The problem is that because salt is an optional argument, no-one reads those docs. Our example code also doesn't give a good introduction, which it can get away with because salt is optional.

By now, I've seen far too many instances of people not supplying salt and introducing security vulnerabilities. There is basically never a case when you shouldn't supply it, the possibility of insecure usage is too high, and often it is impossible to audit. If you are using several third party libraries that use the signing functions without salt, they can easily be introducing vulnerabilities into each other's functionality and this will be invisible. Enforcing salt, and setting good examples of how to use it (e.g. long, fully qualified dotted names as a default minimum) would go a long way to fixing this.

There are also plenty of cases I've seen where functionality can be used to generate signatures of data with a high degree of control by the attacker. For example, a service that signs the PK of an object and returns that to the user (e.g. as an access token), and also allows the user to create many objects, which will have sequentially increasing PKs, allowing the user to get signatures for a large number of integers. These can then be re-used anywhere a sig for an integer is expected. This makes the probability of exploitation higher.

Also, the sooner we can introduce people to salt in our docs, the better. You shouldn't be using signing if you don't have an understanding of the fact that you need to carefully design the scope of a signature so that the signature cannot be re-used inappropriately.

This issue affects `Signer`, `TimestampSigner` and the utilities `dumps` and `loads`.

The immediate issue it brings is that as soon as you start supplying unique salt, existing signatures will break, so people will cheat and do `salt=""django.core.signing""` leaving us back where we were. This is also an issue for rotating your SECRET_KEY - it's too hard to do it without breaking everything, so people don't even when they should.

So my proposal is that we also add utilities to help with this situation. In particular, we should add a `FallbackSigner` which will only generate signatures using the current secret/salt combo, but will also have a list of fallbacks that it will use for unsigning only.

A related issue is whether `dumps` and `loads` are actually useful. If you need to configure signing with a salt argument every time, it is less repetition to specify it once in the Signer and then use that instance's sign and unsign methods. I propose deprecating these utilities."	Cleanup/optimization	closed	Utilities	dev	Normal	wontfix			Unreviewed	0	0	0	0	0	0