Block HA from sending out passwords to third party

You should have a popcorn delivery just prior the the new month release.
I have to admit, the level of “up roar” seems to reach a higher and higher crescendo as time passes …

Or is that just the consequences of Covid 19 lockdown ?

:thinking:

1 Like

It’s a consequence of HA turning against its own ideals. A home automation software that puts “privacy first” (quote HA homepage) and then proceeds to send personable identifiable information to a third party without user consent. Yeah, what could possibly go wrong.

It boggles my mind how anyone at the HA dev team could have thought this to be a good idea. If someone feels they need to be babysit by HA, sure by all means, turn that ‘feature’ on. But not providing an opt-out is, frankly, unbelievable. The uproar is well deserved.

6 Likes

Could be… I wouldn’t be surprised.

1 Like

And the point is they DON’T send any personally identifiable information anywhere… what they do send was clearly detailed a few posts up…

1 Like

Yep, exactly the reason a password checking mechanism has been implemented - because they wish to produce a product that protects you, your HA instance and your home network. With the amount of newcomers that are continually asking for help with rather simple and somewhat trivial issues, it’s no wonder they are trying to protect all-comers.

Can you provide me and example of the human readable data that is sent, and could therefore be intercepted via a MitM attack? I’d be interested to see what evidence that your statement is correct.

Perhaps you were asleep recently when security vulnerabilities were identified within HA, and then rather quickly patched with a number of updates. One would assume that introducing things like password checks is a security mechanism that continues on with ensuring HA is kept as secure as possible.

You are welcome to submit a feature request, perhaps this will be implemented if you do so and it has enough support. Having been around for a while, I have seen many changes introduced and then after community feedback, be adjusted or removed entirely. Just blinding bitching doesn’t help progress your thoughts or ideas around here, I’ve learnt that from personal experience.

1 Like

Does HA also go through my HA managed grocery shopping list to prevent me from buying unhealthy food ? It is not HA’s job to protect me from my own stupidity. If password security is deemed to be an issue, then such a feature can be added with an opt-out.

First bytes of the password hash along with IP (implicit, includes ISP and geolocation) and timestamp (implicit). This is more than enough to start building a user profile over time by a (potentially insecure) third party. You can build user profiles with much less than that. It is also a possibility for the third party to specifically build a list of IPs with a HA instance running behind them.

Oh come on. This is absolutely unrelated and you know that.

I voted.

2 Likes

So it’s human readable, or hashed and abbreviated? If you are so concerned about your privacy, you would already be using a network wide VPN, so submitting IP info won’t be of concern.

It’s not, it’s linked to security and making sure your instance is as protected as it can be.

Good job :+1:

It doesn’t matter if it’s human readable or not. It’s a binary blob that can be used to identify your instance by a machine, with more or less accuracy depending on a number of factors. Ironically, the more unique your password is, the easier it is to build a profile of you. It doesn’t matter if you use a VPN or not.

From a technical point of view, this makes 0 sense. And you can’t argue emotional statements :wink:

1 Like

The whole argument is emotional lol

1 Like

Can’t argue with that.

I mean I’m not even affected personally, I use HA core only. And if I was, first thing I’d do is remove this nonsense from the Supervisor source. But still, it’s an important thing to discuss, regardless on what side you stand on.

2 Likes

Kilobyte? Just like megabyte…

UTF-8 has four bits per character, I assumed a hashed password would be 256 characters.
256x4 bits = 1 KB (kilobyte).

What??
So you mean just because I write an A, that is an ANCI character, and when I write Å that is UTF-8?
That is not how it works.
You set the character set for the document, not each character.
And we are talking the hashed passwords, not the unhashed.
The hashed passwords are UTF-8 (it could be unicode also, but I doubt it).

@Hellis81, no offense, but you don’t understand how UTF-8 works at all.

UTF-8 is a variable length encoding. All ASCII chars up to char code 127 are encoded as 1 byte in UTF-8. So an english text containing only ASCII chars would be absolutely identical in ASCII and in UTF-8. If you write Å, then the UTF-8 encoding kicks in, because the Unicode code point for Å is higher than 127. In the case of Å, it is encoded as two bytes in UTF-8. Most characters of languages other than Asian ones are encoded as two bytes. Asian scripts can use three bytes and sometimes up to four bytes in UTF-8. Technically, it can encode even higher code points as 5 or 6 byte sequences. This changes per character, not per document.

Of course this is all irrelevant in this current discussion. But I just had to clear this complete misconception up.

2 Likes

I did not know, or perhaps I did and forgot the variable length.
That is correct. That will skew the size a lot.

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