This PR builds on#59539 following the discussion that happened there.

Instead of putting the hashed password in the DB to invalidate sessions on password changes, we could store a hash of the hashed password, eg a truncated xxh128 would be fine. This can be implemented in userland with the EquatableInterface. Should we consider making this more "core" somehow?

DB storage and session storage have different security features, so definitely worth it to me yes.
I had a look at other frameworks, and django, spring, Express.js, RoR, ASP.net all have something for that in the mean of a password_changed timestamp or similar token that triggers the invalidation. Notably neither Laravel nor Symfony have anything out of the box on the topic (Symfony stores the hashed password, Laravel doesn't, which means it doesn't invalidate on password changes either IIUC.)

Here is what I added to PasswordAuthenticatedUserInterface to explain what this PR enables:

The __serialize/__unserialize() magic methods can be used on the user class to prevent the password hash from being
stored in the session. If the password is not stored at all in the session, getPassword() should return null after
unserialization, and then, changing the user's password won't invalidate its sessions.
In order to invalidate the user sessions while not storing the password hash in the session, it's also possible to
hash the password hash before serializing it; crc32c is the only algorithm supported. For example:

publicfunction__serialize():array   {$data = (array)$this;$data["\0".self::class."\0password"] =hash('crc32c',$this->password);return$data;   }

Implement EquatableInteface if you need another logic.

crc32c is selected because its probability to change when the password hash changes is high, so that the invalidation of sessions is effective. But it's also selected because there are many possible valid password hashes that generate the same crc32c. This protects against brute-forcing the password hash: let's say one is able to find a password hash that has the same crc32c as the real password hash: one would still be unable to confirm that this password hash is the correct one. To do so, they would have to brute-force the password hash itself, and this would require brute-forcing bcrypt et al. The cost of doing so on one bcrypted-password is already prohibitive. Doing so with a very high number of possible candidates (as collisions are generated) would be even more prohibitive.

Note that to generate a collision, one just needs to generate a random string that's formatted as a real hash, like this line for a bcrypted-password:

'$2y$12$'.substr(strtr(base64_encode(random_bytes(40)),'+','.'),0,53)

(one could likely create a crc32c-aware collision generator for this purpose, but that wouldn't reduce the difficulty of validating the generated hashes).

On the contrary, using a more collision resistant hashing algorithm would make it too easy to validate that a generated hash is the real hash.