No we don’t. That patch is just a band aide. When there is an opt-out or the function is removed, then we will have a working solutiion.
3 Likes
it was attempt to use irony to support John’s statement. hence emoticon
My $0.02 worth (and with everyone else on this thread it comes out to a tidy sum when added up!)…
I think that it is a bit of nannyish to force people to comply with someone’s idea of how you should manage your passwords, but I support a bit of a nudge in the right direction. This is not a nudge, it is a hard push.
When dealing with web sites, I completely understand and support their password rules because that’s publicly accessible, but my home network is not published to the Internet. There are those that will say “oh you think your home cannot be compromised?” and I’m not so naive, but I also realize that if they breached my firewall in the first place then they probably won’t have much trouble getting into pretty much anything else I have in my house, so this is an exercise in futility.
I’m quite security conscious. I use password managers and have, literally, a different 30 character secure password for every publicly accessible account I have. For my internal network I don’t use passwords like “Password”, I use complex passwords, but I have just a few memorized passwords that I use that meet any complexity requirement out there. Just because I used those memorized passwords online at one point in time doesn’t compromise my internal network and my password manager also lets me know when there has been a breach so those passwords were changed ages ago and never get used outside my internal network.
Also, while I have no problem with applications that audit my passwords I have a big problem with that password being checked against an online site without my permission. HASS has crossed a line by sending my password to haveibeenpwed. If I was the target of a hacker and they have spyware on my system that I’m unaware of then HASS just sent a request to a site that has my IP address and at least one password. What happens when haveibeenpwed gets hacked (and they will) and the hacker goes through the logs and sees a request from my public IP to check a password out? They will use that password as their first test to see if my firewall might share the same password, and if it doesn’t then why not hack my firewall and then go to town on every device I own using that password? And since my SSH and my Samba passwords are different, they actually have two. What’s next? Sending every password in secrets.yaml to this site I have not authorized? This is not ok.
All of that being said, it’s the responsibility of the user to decide if they want to use a password and the complexity of that password, I don’t need HASS “big brothering” me by nagging me like shareware throughout the day, thus rendering the usefulness of notifications to zero since I have to ignore them now.
My opinion has been stated, I think this is something that should absolutely be a toggle in HASS. In the meantime, I’m not going to whip myself into a frenzy over one questionable change to an otherwise great piece of software that works great in every other aspect. I’ve added the great automation above, I’ve added domains to my Pi-Hole to stop this nonsense and I move on.
6 Likes
To be fair, the entire password isn’t being sent. It’s the first 5 characters of a hash of the password. I’m not condoning the action at all. Just pointing out that it’s not the full password that is being sent.
1 Like
Valid point, thank you for the clarification!
1 Like
What you and others are describing is exactly what is not happening. It is the first bullet point listed in this section from an article about how k-anonymity is being used for the purpose of validation. The first bullet point out of 2, which are being used as examples of inadequate methods. The whole article is worth checking out.
Reading further you can find that the first few characters are hashed/mangled, and then that is anonymized. A matching range of passwords is grabbed and downloaded and the check is done locally. (my description is oversimplified).
So yes, let’s assume notification dismissal is on the way. Conjecture and misinformation about the actual process is what fuels the Frenzy Loops. The community add-ons have done this for years now and the main difference is that a user can go in and change a setting to stop it. So, the difference here is the dismissal of the notification.
Another issue I’ve seen is that some add-ons are defining pins as passwords, which causes those to get checked. That should should be changed by the add-on dev so that a pin doesn’t count as a password.
5 Likes
That means “they” at havibeenpwd at least “know” I (my IP address) am using that password?
Worst (way way worst) case: “they” “know” you’re using one of around 500 passwords matching that hash. But not for what or in combination with which username.
HIBP does have a log of your external IP address (which is usually a DHCP address from your ISP and should change rather frequently as static IP addresses would be much easier to trace back). However, HA is only sending the first 5 characters of a hashed password. Meaning, your actual password isn’t being sent out.
So, while HIBP does know when and from what IP the request was sent, they don’t have any way of reversing the password hash to a readable password nor is it tied to a user name. No attacker would be able to do anything with the information HIBP stores in terms of logging.
With all that said, that’s not my complaint in this process. My complaint is an unsolicited external URL request originating from HA that I did not explicitly authorize. The notifications and the pwned add-on do not affect me as I use Core only in my production environment. As such, my fear is that the devs will migrate this functionality into Core at some point and I am VERY much against that.
1 Like
i’m sure it has been explained already what are benefits given to hacker from knowing part of a hash.
We are doing circles actually.
Really wandering why devs (the project owner) are mute about it. It’s hard to understand their design decissions. But lack of transparency and feedback after prooving that the feature is total fail is really worrying me.
For homeassistant… thats what is using an api, nothing else does in my network 
And why would they know it’s Home Assistant that is doing the request?
It’s just “one” request in thousands per day
Oh man, that is a good idea. I would definitely like to know of integrations using known passwords with external services. So: A hell yes please, sign me up! 
5 Likes
Why wouldn’t they? I never had a device pitching that api in my network and suddenly it does it multiple times a day? That’s not rocket science… and most probably there is also a fingerprint in the api query, but thats just guessing.
Please sign me out 
1 Like
That just has to be HA… NO WAY it can be anything else…
There are apps and other software using the same API, maybe “you” already used their service before HA did without you knowing.
It’s not your Home Assistant password. It’s the passwords you as a user have chosen to store in cleartext in secrets.yaml. Which could be used for e.g. (but not limited to) any of the nearly 2000 services listed here: https://www.home-assistant.io/integrations/#all
Edit: This turned out to be untrue.
LOL @frenck I have always had the utmost respect for you and the other devs I have interacted with over the years here (and I still do). However, can you really tell me that if the pwned add-on had gotten a warm reception by the community, that there isn’t some part of you that wouldn’t like to see it modified to scan the secrets.yaml file (and or other *.yaml files and/or integrations) in Core? I mean, it’s really not that big of a leap code-wise to replicate the functionality.
That’s my fear and honestly, it isn’t even about passwords (hashed or otherwise) being sent out. It’s about the Home Assistant mantra that it is a privacy and local first project. Calling out to any external service without the user’s expressed permission violates that mantra regardless if it is for something beneficial like password checking. It’s also part of the reason why I don’t run Supervisor (except for dev testing of things).
8 Likes
The user-agent string would identify it. Although, I’ve actually never tested or looked at what the UA string is from Supervisor outbound. Most likely, it’s just the generic aiohttp default user-agent.