I'm really glad you asked. The way we handle that is before you send the password to us you apply a secret salt known only to you and hash it using a secure hashing algorithm. When you provision your breach database with us we also hash every entry with the same secure salt. We then delete every trace of that salt.

Then no plain text password is transmitted to our service from you. In order for us to recover your password we would have to know your secret salt and run a dictionary attack on the hash you send us. But if we could recover your password with a dictionary attack then we would have advised you not to use that password anyway since that is the service that we are offering. We basically run a dictionary attack on every hash you send us and advise you not to use any passwords that are found in entries in a breach list. So if we could recover your password it would not be secure from the point of view of the service we are offering. And if we cannot recover your password then it is secure from the point of view of the service we are offering.

When we discover a match between the hash you send us and your breach list we still do not know what the entry in the breach list is. And if they discover such a match or a derivation of we would advise you not to use that password. We are only advise you to use passwords which we cannot find any matches to. Only the passwords which we know nothing about except that we cannot find a match to them anywhere.

The next thing to note is even if the attacker somehow recovered your secret salt they could attack our system in two vectors. They could have man-in-the-middle capability and try to reverse hash all passwords you submit to us. However if the hacker is able to find the password you submit then our aim is to have suggested to you to not use that password because the hacker would likely use a breach list as we do. Another type of attack is the haka could gain control of a server and have your salt and then recover all the entries in the breach list. However this does not really gave them anything because at that point we would have suggested to you to not use any passwords that match any entries in the lists.

So if you send us a secure password both we and any attacker who is able to gain control of the server or a man-in-the-middle capability will be unable to obtain your password under the assumption they are using breach list and and derivations. This is not perfectly secure however I feel that the risk reduction only by permitting reduced breach risk passwords into your system is greater than the risk of the attacks we just talked about.

Perhaps the scariest weakness to the system is an attacker can craft responses from a service telling you to go ahead and use insecure passwords. To me that's the real vulnerability of this type of system. We can only trust TLS up to a certain point when considering the breaches of the last few years. In order to be hardened against such attack I'm considering some sort of message signing so you could verify the server response really came from us. But what I'm talking about now is more a general class of weakness not particular to this vetting scheme.

All these things considered I feel cautious but I do feel the risk reduction of having a password vetting scheme outweighs the risks using this scheme I've described here. If you can spot any more weaknesses in this please go ahead and let me know.

I tried to explain this clearly but I don't really feel the language is correct I'll probably try to edit it a little later plus apologies for any mistakes I'm using voice typing. Thanks for the question let me know if you got any more please.