So using it is not without risk, but given the service is run by a generally highly regarded security researcher, the risk is probably still smaller than allowing for known-breached passwords because we don't have the capacity to have more than a few hundred thousands items on our bad password list, so maybe it is worth the risk?

It'd certainly be possible to do it locally, but we'd need to throw some proper db resources at it, plus future updates/maintenance etc.

We'd certainly need to loop in legal before doing that... And work out about what wgCopyUploadProxy does (logging etc) too

(bringing over a related thread from elsewhere)

In T189641#4790454, @Volans wrote:

Why "k-anonimity offers very little defense"?

It only means the attacker has to try k passwords instead of one. With k being a few hundred, that only makes a realistic difference if you use super strict rules for bad logins (e.g. lock out the user completely after some amount of tries, like banks do). I guess a wiki could use very aggressive bad password throttling specifically for login attempts with weak passwords (a few per day or month) and in that case it would make a difference, but not with the default setup.

But you're sending to this API only the first 5 char of the SHA1, that returns ~500 SHA1 hashes that match that prefix and the client checks if the hash of the password under test is part of this list or not. So the malicious service doesn't know if the check was positive or negative.

If the password was known to the service, k-anonimity only means that it needs to do a few extra attempts (hundreds, or even tens of thousands of login attempts are easy to pull of against almost any website if the attacker draws them out a bit). If the password was strong and unique then the full hash would be equally useless to the attacker so k-anonimity makes no difference. For a mediocre password that has not been leaked yet but can be bruteforced, it does make a difference, so in that regard I did undersell it.

The malicious service at most knows that you tested a password of which the first 5 char of its SHA1 are known. It could, of course, work under the assumption that all the tested passwords are positive (but it doesn't know it), and start trying all the ~500 passwords on the website that made the check, but for which username? It doesn't have any info about those, so it should try them all.

MediaWiki keeps a public log of account creation, so for a public wiki it's trivial to correlate. Even if it's English Wikipedia there are only about five account creations per minute, plus a few hundred logins, so with the timestamp you could correlate every account creation with the 10-20 hash prefixes sent in that second. On a less huge wiki the service could reliably pinpoint the account name.

On smaller wikis, some of the logins are not impossible to deanonimize either, by looking for users who had a long period of inactivity followed by activity shortly after the password check.

On smallish wikis just going through the full user list is an option as well.

In any case k-anonimity does not change anything about this - the attacker just has multiple passwords to try instead of one.

Moreover, on account creation/change password if the password is in the list it should be forbidden to use it, so not risk here.

That only helps if the service is honest. It can omit some of the bad passwords known to it from the response (which will also narrow down the list of passwords to try, if the assumption is that the wiki prevents the use of passwords that are returned by the API).

Note to self: do not reply to a complex topic on a Friday night
True, if the usernames and user activities are public there are lots of information available for a malicious HIBP site.