If somebody inside my private network already then weak HA passwords my last problem. You clearly got no idea about IT threats.
1 Like
Not only would it overflow the usual media outlets, it would most certainly trigger legal action against Microsoft.
I read the blog from the HIBP owner. What can I say. It’s exactly that kind of I’m always right and you’re wrong if you don’t agree mind set that makes anti-features like this one possible. But @CaptTom said it much better than I could in his post above. If anything, it made me lose the last yotta of trust I could have had in the HIBP website.
Anyway, I’m out of this discussion. It leads nowhere. This isn’t about the feature anymore, it’s about the ego of certain devs who just can’t handle the fact that the community pushes back on one of their pet features. I use HA Core only, so I’m not (yet) impacted. At least I can always patch stuff like that out of the code. If things like that become the new norm, I’ll have to find a way to manage my home without HA in the future.
4 Likes
Your passwords are not sent anywhere, how is it using your data without your permission? Your passwords are NOT sent anywhere.
Take time to understand how it works before getting angered by it.
I bet you didn’t get this upset when your browser started checking your passwords.
1 Like
A disable feature is coming. I’m locking this thread because it appears that personal attacks are ramping up… again.
2 Likes
This topic was automatically opened after 22 hours.
I never said they were?
Homeassistant is using the passwords (data) in a way that was not intended or consented to by the end user. The end user added the password with the sole intention to connect to a specified service, homeassistant is using it to compare against a list provided by a third party who may or may not be trusted by the end user. There are many reasons why people may not want to use this service, and that should be their choice.
I feel like I already covered this, but I NEVER said they were?
I do understand how it works and I am not angered by it. I have not been adversely affected by this change and always use strong unique passwords and additional authentication options wherever possible. As I pointed out in my post (that you chose to ignore the contents of, but reply to anyway) it is the enforced delivery and poor implementation of the feature and the subsequent behaviour of people who should know better that is a problem here, not the feature itself.
That said, if HIBP was ‘sold to the highest bidder’ tomorrow I would want the option to disable this feature until I had the opportunity to decide how much I trust the new owners - anyone who argues against the concept of a toggle switch for this feature is asking for trouble purely on this basis alone. Even the owner of HIBP agrees! Therefore, this feature should not have been implemented ‘gung-ho’. Five minutes of thought before mucking around with people’s private data should not be too much to ask, especially on a platform that bills itself as privacy conscious.
Interesting. Either you don’t understand the difference between a website and a browser, or you’re talking about a built-in password manager. I’ll assume the latter…
Browsers’ password managers can be turned off. Presumably you leave yours switched on. That’s cute. Browser password managers are generally not themselves password/2FA protected, don’t generate particularly strong passwords and are tied to the browser - you should consider using something more secure.
6 Likes
Thank you!!!
Can you offer any more details? Is it a full opt-out or does it just suppress the nagging? Can the checks be allowed but less frequently? Only at the first use of the password?
And, of course, when will it be available?
Since making the change without much discussion didn’t work out so well, perhaps having a discussion about the fix before implementing it might not be a bad idea.
3 Likes
I have no idea. It will most likely satisfy the feature request that sparked the change in the first place.
No clue, but you can watch the PRs and see when a change is made.
Continue the discussion in the feature request.
IHBP fails that test too. Lots of ridiculously long pass phases fail their test too. IHBP is a “one size fits all” processes that does not encourage best practice password/phases. Take a really bad password add an ! or * on the end and suddenly it passes IHBP… It is still a terrible password.
If this was a problem, force a two factor authentication. Any system that “lives” out side of your firewall should have 2 factor turned on as well as an IP block for failed attempts… That is pretty much the best that a home user can do.
The fact that every HA Pi is “pinging” the HIBP service every hour, in an incredibly inefficient brute force manner makes me think that something else is at play here. Any reason that IHBP would want to see a significant increase the use of its service?
2 Likes
My 2 cents…
The use of an external service receiving user data, even if only the IP address which allows at least for geolocalization, falls within the definitions of “personal data” according to Art. 4 of the European GDPR.
This requires explicit consent received from the data subject (i.e. the user), as for example the same happens for the use of cookies when browsing websites.
Therefore the user should give explicit consent to the use of his data by the HIBP service, since a generic consent to use of the Home Assistant system and services cannot be considered sufficient.
Moreover, according to the Art. 13 GDPR, the user should have been given detailed information about the controller, included the identity and the contact details of the controller i.e. the IHBP, and even have the right to object (Art. 21 GDPR)
Finally, everything considered, “Without prejudice to any other administrative or judicial remedy, every data subject shall have the right to lodge a complaint with a supervisory authority, in particular in the Member State of his or her habitual residence, place of work or place of the alleged infringement if the data subject considers that the processing of personal data relating to him or her infringes this Regulation.” (Art. 77 GDPR)
11 Likes
what’s the IP it checks with? I can simply block that in my router. Not happy with this leak of hashes leaving my network without my control, knowledge or permission.
I have a device which I have firewalled all IPs except those necessary, but it has password limitations of 6 characters and numerals only.
3 Likes
Thanks. Job done, IMHO.
1 Like
This check “only” looks at supervisor and add-on passwords, so your device will not be checked against this list.
To anyone interested, the password check can now be disabled with the command below in the CLI using the latest versions of either the core-ssh add-on or the community ssh add-on:
Terminal & SSH (core) version 9.1.0
SSH & Web Terminal (community) version 8.0.4
ha resolution check options --enabled=false addon_pwned
and then ha host reboot
33 Likes