We have a requirement for a security audit that our password policy must disallow the re-use of a previous password from the last 4 used passwords.
We can accomplish this fairly easily by making a call to the server to allow it to compare the password candidate against the database's previous password hashes, but that introduces some lag time in transit. Our managers have asked us to investigate if we can eliminate the delay by implementing a pure client-side solution.
Therefore, my question focuses purely on the feasibility of a safe client-side solution.
Assume that a MITM attacker has found some means to gain access to the payload via HTTPS or client-side application vulnerability.
The only process I have been able to devise would be to transmit the previous password hashes with their server-side salts to the client ahead of time.
The requirement of needing to send the server-side hashes with the password hashes is what presents the inherent risk in my estimation.
Without the salt, then the client would be unable to test the candidate password against the password hashes. However, sending the server-side salt to the client-side exposes it to a potential MITM attacker.
If the attacker was successfully able to bruteforce the current password hash among the previous password hashes, then they could change the password under the nose of the current user.
This exploit could be exasperated if a user requested to change their password, was sent the previous password hashes + salt, and then chose to abandon the changing of the password. This would give a MITM attacker plenty of time to find a suitable entry for the current password hash + salt, and subsequently change the password.
Even if the attacker wasn't able to crack the current password in time, they'd still have plenty of time to crack and use these passwords on other sites where they may not have been updated.
I've been advised by peers that this might be overly cautious - that hashing functions like Bcrypt would take so long to bruteforce that it's practically impossible even with the salt exposed to the attacker...
In my estimation, this is equivalent to the result of a SQL injection attack. Nonetheless, I'm having trouble convincing my peers...
Is this method of checking if a password candidate would collide with a previous password unsafe? If so, is there another mechanism that would be safe, but which does not require remote calls to a server?