> Wait, if you query HIBP, you are actually asking: is it safe to use thus password?

I agree - this is the main use of HIBP.

> If you have a match, you will certanly use different password.

I doubt this is true in all cases. Sometimes people get lazy. But nonetheless, a malicious actor could still capitalize on the few minutes between a user checking a password on HIBP and that user changing their password. For example: for every password lookup, pick the most likely password with that hash, and if it has at least 90% share of the passwords with that hash, try to correlate an email address to their IP address (using leaked dumps), and then try to log into gmail with those credentials. Even if it works 1% of the time, a lot of harm could be done in a few minutes. (For example, US Social Security Numbers may appear in a years-old employment document in the email).

> And, by the way, they have username/hashes before you even use their API.

But they don't necessarily have yours. If I am somebody who uses a different password on every site, and I check a password for a site that has not had a leak, then they do not have an association between my email and my password before my query, and they do after my query.

Regardless of the particulars of possible exploits, I'm mainly claiming that the original comment above (by @matsemann) is not true, in that some level of trust in HIBP is necessary to input a sensitive password.

This isn't really the way HIBP is used. While you can query the HIBP endpoint, the hashes are also available as (large) torrent downloads too. For many use-cases this means as the HIBP operator you won't see those requests since other service providers are likely using a local cache and not taxing Troy's infrastructure. Even when you are directly querying, the request is very likely proxied by the service operator so you won't be able to derive IPs specifically, just someone using Okta tried the password `obscure` (but not that they set their password to this - whomever they were, note I'm not saying Okta directly queries - just an example). Further, security recommendations (eg OWASP) require that companies test potential passwords against known leaks and discourage or prevent users from using frequently found values (typically 100+ uses or leaks.. note this either means one user has unluckily been leaked 100 times, or 100 people have used the same password) - this again encourages both proxied and possibly cached lookups (vs trusting client side code which could be disabled). Note that the expected use case is at password creation or password change, the new candidate is tested - not upon every login.

Ok so many use cases are removed - maybe your locally running password manager allows you to test a potential new password against leaks. Now we have a rare example of what you're hypothesizing, at this point you're trying to tie an IPv4 address to an identity. Many networks have either shared IPv4 addresses (NAT/GNAT in major metros, corporations, public Wifi), or dynamic IPv4 addresses (change daily/weekly/monthly). It's pretty hard (though not impossible) to link an IP to a person.. and vice versa, between 3g, 4g, 5g, wifi, work, home, complementary, wired and wireless connections a single person may appear across several addresses.

Finally the idea of accounts - knowing a specific IP just tested the password `password` and Aretha Franklin is most likely at that IP.. well, which of the hundreds of services might she be potentially considering the new password for? (again - testing, not setting the password to). If you could narrow it to one service, or brute force all of them, and assume the user ignores the dire warnings, you still need to know their user credential (be it email - of which they may have many, username - of which they may have many, or service-generated username which you'd need insider knowledge to obtain)

If you're worried about trust of your sensitive password, your password manager and the service you're using it on (if you reuse passwords) need far more.