It doesn’t matter at all, because this is not the way hashed passwords are transferred to the API. They’re encoded as hexadecimal chars.
I think the discussion in this instance was not about size of data sent, but downloading the password list locally and using so nothing is sent out, problem is those list are still large downloads
This was an interesting read, thanks for this. I make random passwords for everything, even local stuff so I’ve kind of been watching from sidelines on these discussions without a strong opinion either way. But this gave me pause since it adds some risk to using the service, even if its small in my case.
I do emphasize with the HA dev team here. If you search “hacked” in the forum there’s a lot of posts that can be basically summed up as “user turned off security and exposed it to the internet”. I can understand they want to have a more opinionated view on security to protect their users, their brand and the time of their developers.
But overall I lean more toward there should be an opt out because I like user control. And now this article pushes me further in that camp.
3 Likes
The API call returns a list of matching hashes the same way, as hex encoded chars. If you wanted to download the entire db, then the encoding is pretty much irrelevant anyway. You’d just download a big zipped binary. Which would have to be updated all the time. No, that’s not a manageable approach.
The solution is very simple - request user consent before doing the first call. And provide a permanent opt-out checkbox on the initial consent dialog.
2 Likes
At the moment I believe the risk is small.
We do not know the future of HIBP. It’s been up for sale and I don’t know how well maintained it is. The article also states an attack towards a dedicated instance. If you reverse it and target all those who have hash-checks sent out, you get a pretty neat list of those who are vulnerable.
The flip side of SHA is that every time someone does a hash check and send the same request, it basically tells me, this password has not been changed…
3 Likes
I’ve blocked it from accessing the api using PiHole but I STILL get persistent notifications! How do I stop those, please?
21-03-06 07:40:49 WARNING (MainThread) [supervisor.utils.pwned] Can't fetch hibp data: Cannot connect to host api.pwnedpasswords.com:443 ssl:default [Connect call failed ('0.0.0.0', 443)]
21-03-06 07:40:49 WARNING (MainThread) [supervisor.utils.pwned] Can't fetch hibp data: Cannot connect to host api.pwnedpasswords.com:443 ssl:default [Connect call failed ('0.0.0.0', 443)]
21-03-06 07:40:49 INFO (MainThread) [supervisor.resolution.checks.base] Run check for IssueType.PWNED/ContextType.ADDON
Is there some kind of cached file it is referring to to allow this?
Thanks.
Something like this should work in your configuration.yaml file. You may have to play around with it.
logger:
default: warn
logs:
supervisor.utils.pwned: critical
supervisor.resolution.checks.base: critical
1 Like
You can’t.
If you don’t believe then read up on the topic. But you can’t reverse a hash. It’s impossible.
You can brute force a reverse map but that will take “forever”.
That’s what I’ve done, a big advantage is that I don’t get the insecure warning on Chrome now for my internal never on the internet routers that have default admin/admin
Frankly, this whole ‘insecure password’ thing is way too simplistic and a hammer to crack a nut.
It’s like saying ‘somewhere on the Internet, someone else is called John so you must change your name’ - it’s barking mad. Without at least some other information the password alone is useless (or next to useless).
How many passwords have been compromised globally? Millions? So even if the bad guys were to bypass EVERY OTHER layer of security you have, AND know the other authentication factors they would STILL have to run millions of passwords at your system - or get lucky!
And for this we have well meaning developers the world over lecturing and badgering us! Apply some logic, folks - please!
1 Like
That’s exactly what they do.
1 Like
You missed one part.
They don’t even have the password.
They have the hash of the password.
So even if someone download the full list (which is possible) then you would still have to “un-hash” the list of millions of passwords.
Un-hashing one password is deemed to take to long for it to be used as a method of a hacking. Now do that on millions of passwords…
I haven’t looked at the list, but I suppose the optional salt is not included, making it even harder.
Who? The developers?
The hacker / botnet controller.
They try billions of known passwords until one works.
That’s why hibp exists
1 Like
That is why you only get a few attempts before an account is locked.
Your mqqt server or samba server lock after a few attempts do they? Not sure that’s true 
1 Like
Right - and you have NO OTHER detective controls for such unexpected behaviour?
With email addresses and other credentials, yes, it is a very real threat - with this type of private system, on protected networks, it isn’t. Well, it wasn’t until someone decided to start beaconing on my behalf and without my permission!
1 Like
Most reasonable systems lock down when you enter the wrong password too many times.
Not sure how yours is set up.
I don’t know, do you? Does every user? Especially the ones stupid enough to use admin as a password.
Many servers come default with admin or hass as a username so that’s a good starting point for a hack.
Which is exactly why we need this to be optional! On by default, OK. Requiring some skill or experience to turn off, OK. But let those who want to turn it of and have the knowledge and skills required to do so turn it off!
2 Likes