It's not so much that the password hash is updated as it is that the update is calling CentralAuthUser::setPassword() with $resetAuthToken true, which changes the auth token. But the User object being used by CentralAuthSessionProvider has a different CentralAuthUser instance, which has already been loaded and doesn't know there's a new auth token, so it winds up storing the old token into the session, so the session fails to load on the next pageview.

Two possibilities for fixing this come to mind:

• Arrange for CentralAuthUser::getInstance() to return the same instance if passed two different User objects for the same user.
• Set some sort of flag to tell other CentralAuthUser instances for the same username that they need to reload.

Change 271803 had a related patch set uploaded (by Anomie):
Track CAS tokens for loaded users

https://gerrit.wikimedia.org/r/271803

In T127396#2044404, @Anomie wrote:

• Arrange for CentralAuthUser::getInstance() to return the same instance if passed two different User objects for the same user.

That would solve other problems as well, see T127236.

Change 271803 merged by jenkins-bot:
Cache CentralAuthUsers more aggressively

https://gerrit.wikimedia.org/r/271803

Change 272642 had a related patch set uploaded (by Paladox):
Cache CentralAuthUsers more aggressively

https://gerrit.wikimedia.org/r/272642

Change 272642 merged by jenkins-bot:
Cache CentralAuthUsers more aggressively

https://gerrit.wikimedia.org/r/272642

Change 273273 had a related patch set uploaded (by Paladox):
Cache CentralAuthUsers more aggressively

https://gerrit.wikimedia.org/r/273273

Change 273273 abandoned by Krinkle:
Cache CentralAuthUsers more aggressively

Reason:
Was intentionally not backported to wmf.13 yesterday.

https://gerrit.wikimedia.org/r/273273