Improper Verification of Cryptographic Signature in django-rest-registration

Misusing the Django Signer API leads to predictable signatures used in verification emails

Impact

The vulnerability is a high severity one. Anyone using Django REST Registration library versions 0.2.* - 0.4.* with e-mail verification option (which is recommended, but needs additional configuration) is affected. In the worst case, the attacker can take over any Django user by resetting his/her password without even receiving the reset password verification link, just by guessing the signature from publicly available data (more detailed description below).

Patches

The problem has been patched in version 0.5.0. All library users should upgrade to version 0.5.0 or higher. The fix will invalidate all previously generated signatures , and in consequence, all verification links in previously sent verification e-mails. Therefore semi-major version 0.5.0 was released instead of version 0.4.6 to mark that incompatibility.

Workarounds

The easiest way way is to disable the verification options by using something like the minimal configuration described here. This will unfortunately disable checking whether the given e-mail is valid and make unable to users who registered an account but didn't verify it before config change.

Less harsh way is to temporarily disable just the the reset password functionality:

REST_REGISTRATION = {
    # ...
    'RESET_PASSWORD_VERIFICATION_ENABLED': False,
    # ...
}

Which should disallow the worst case, which is account takeover by an attacker. The attacker can still use the register-email endpoint to change the email to its own (but it is less critical than resetting the password in this case).

If one already set 'RESET_PASSWORD_VERIFICATION_ONE_TIME_USE' setting key to True in REST_REGISTRATION Django setting (which is not the default setting) then it should mitigate the security issue in case of password reset (in this case, the signature is much harder to guess by the attacker). But even in this case upgrade to newest version is highly recommended.

Technical description

After the code was refactored to use the the salt was passed wrongly as secret key, replacing the set in Django settings file. This leads to the Django not being used by the signer object. The secret key of the signer ends to be the salt which in most cases is a static string which is publicly available.