Their docs link to this explanation, in which the link I give uses an example that appears to be identical to the HA implementation - https://blog.cloudflare.com/validating-leaked-passwords-with...
I might be misunderstanding, but if the first 5 digits is a unique hash in the HIBP database then an attacker can replay that request, then lookup the hash. But "When hashes are grouped together by a Hash Prefix of 5 characters, we find the median number of hashes associated with a Hash Prefix is 305." {ibid}.
If you've acquired leaked passwords as HIBP have, you then just make hash lookup tables, then you have 305 potential passwords to try, or try and whittle down. If the bucket of hashes has "hunter2" in it, for example, then that's perhaps a good one to try - https://blog.cloudflare.com/validating-leaked-passwords-with... is worth reading.
according to that sharing a part of the hash is a risk. it could for example end up in logged urls somewhere. it's a pity that the argument revolves around absolutes ("this is bad", "no, it's not") instead of actually investigating and explaining why they see a problem here.
Even if the SHA1 isn't totally negligible in cost, if they're attacking many users at once they can share the SHA1 work across all of them (as it's not salted) making it marginally negligible. So someone attacking a sha-1 salted password database with a million users where they have the 20 bit unsalted sha1's still gets a similar speedup, even though the 'hard' hash is just as fast as the easy one.
Security aside, -- if you use some old crap password on internet isolated IOT devices that HA can reach (as some people I know do)-- then the 5 characters is a one in a million identifier which probably uniquely identifies you. The database sees your IP address and so you've probably connected to identity (via old leaks) to your IP to them and anyone surveilling your traffic. You've also connected your old weak passwords to that IP, so someone that gets access to it would have a ready database of plaintext passwords to use to initialize a password search against any exposed endpoints.
Even just making the request at all exposes information about the software you're running, that there are devices at that IP (which otherwise might be inbound blocked), etc.
I think the privacy concern is much worse than the security one: For security you can change any exposed passwords, presuming they didn't get you hacked yet. The privacy loss is far more irreversible.
Many people use home assistant in order to avoid security and privacy violating cloud services, so this is a significant disappointment.
Imagine if your smart toilet would just send a small anonymized message to a urine sampling analysis service so it can let you you know your cholesterol levels are a bit high, totally anonymous, totally for your benefit. Maybe it's a great feature, but would anyone expect this to happen without consent / opt in?
As he said: "This mechanism could be abused by a malicious threat actor with access to the home assistant github repos in a variety of ways." -> If you get access to write to the Github repo, yes in fact you can for sure do much more damage without ever touching this feature.
Also "I can give you a list as long as my arm about how I could abuse this to loot credentials from every HA install on the planet." -> Waiting for it.