In an IRC discussion relating to session storage T206010, concern was expressed that AuthManager's storage of the encrypted password in the session provides attackers with access to the plain text password under plausible threat models, such as remote code execution as the www-data user.
The reason AuthManager stores the password is because it is sent by the user on the initial POST request, and yet the password validity needs to be checked in the context of later requests.
My idea is to call a form processing method on all registered AuthenticationProvider instances when each form is submitted. This method will return a data array giving only the data the AuthenticationProvider will later need to authenticate the request. Then beginPrimaryAuthentication() will only be passed the pre-filtered data arrays previously returned by the form processing method, instead of all form data.
For example, LocalPasswordPrimaryAuthenticationProvider could just store a boolean value representing whether or not the password matched. This would minimise the amount of sensitive data stored in the session, although at the cost of allowing the login if the password was changed halfway through the authentication process. If it's a requirement to abort the authentication process when the password is changed, then a hash of the password could be stored, although this brings with it the risk of disclosing weak passwords to an attacker by hash inversion. A last-change timestamp or serial would be a more secure way to detect a change of password.
LocalPasswordPrimaryAuthenticationProvider also needs to know the password validity so it can set the reset-pass flag. The form processor could serialize the Status object it gets from User::checkPasswordValidity(), to avoid the need to call checkPasswordValidity() in a later request.