Updating Password Hasher Invalidates Users First Login After Upgrade

[Simon Blanchard]

The code below, from contrib.auth.base_user.py, says "hash upgrade is not a password change"

    def check_password(self, raw_password):
        """
        Return a boolean of whether the raw_password was correct. Handles
        hashing formats behind the scenes.
        """
        def setter(raw_password):
            self.set_password(raw_password)
            # Password hash upgrades shouldn't be considered password changes.
            self._password = None
            self.save(update_fields=["password"])
        return check_password(raw_password, self.password, setter)

but the code in contrib.auth.get_user() verifies the session by comparing a salted hmac of the password hash to the same thing stored in the session.

If we update the password hash the salted hmac will change. Therefore, the session will no longer be considered valid and will be flushed. We can keep the session alive by updating the HASH_SESSION_KEY in request.session e.g. via the update_session_auth_hash() function. But this is not called by the setter function when the hasher is updated.

So the first time the user logs (with the correct password) following an upgrade, their (valid) session will be flushed and they will be logged out again.

[Tim Graham]

Here's my understanding of the scenario:

1. User X logs in and creates session A
2. Number of hash iterations changes in Django due to a software upgrade
3. Session A is still valid at this point
4. For whatever reason (using a different browser perhaps), user X logs in and creates session B, triggering a password hash upgrade and an invalidation of session A

I don't think there's a way to keep session A valid is this scenario. Am I misunderstanding something?