Lol that’s a neat trick. Will be undone every supervisor update but could just be started on a schedule or something. Props
That’s fantastic, and it shows the kind of can-do spirit which makes HA such a great product. Thank you!
That said, I hope this add-on doesn’t become “the” solution. It’s one thing to hack out a patch to fix something stupid in a package (I did a lot of that during a long IT career) but as you say, there is risk and administrative overhead.
The right solution would be to put in a proper opt-out in the base code. An additional option to run it on a less frequent basis would be nice for some, but the most critical piece is the opt-out.
1 Like
If you leave it in enabled to run on start it’ll do it every time HA is restarted, I wouldn’t recommend doing that as the next update may have a breaking change so it would be worth investigating before running it.
I agree, I hope to not have to maintain this into the future. Like I said, I get both sides of the argument, but scheduled checking of passwords is definitely not the way to go about it.
If you must check my credentials do it when I’m saving the edits, and even then don’t stop me from saving my edits, you’ve done your due diligence and informed me I’m doing something you disagree with, now let me do it anyway.
2 Likes
This is about passwords within add-on configs. That’s it.
Sorry to cross-post, I mentioned this over on the feature request thread, but…
I haven’t gotten a notification in two days, possibly from around the time I updated Supervisor to 2021.03.03. My automation blocking the notifications hasn’t blocked anything since then, either. Anyone else seeing this?
The addon doesn’t copy the new addon_pwned.py in my installation.
But putting the content by hand solves the password notification problem. So thanks for that.
The new release installed today but no opt out for this annoying thing. What is wrong with the developers?
1 Like
We already have the working solution, though 
Which “new release” are you referring to?
If you mean the latest patch release of Home Assistant (currently 2021.3.3) it plays no part in checking for pwned passwords. That function is performed by Supervisor and the latest version of Supervisor is currently 2021.03.4 which was released 5 days ago.
If you are interested in learning what changes the development team is making to Supervisor, you can read the open/closed Pull Requests in the Supervisor repository.
1 Like
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 