Block HA from sending out passwords to third party

samnewman86 · March 6, 2021, 9:53am

I don’t see any option for this in the samba add-on or mqqt add-on, the servers most people use.
Maybe they do but as a dumb user would I know if and how to use this

samnewman86 · March 6, 2021, 9:54am

The trouble is some of ones who think they have this knowledge, seem to have very little.

Hellis81 · March 6, 2021, 10:00am

But the account to HA can be banned after a few attempts.

If you use Nabu casa then they can’t even trace back to your HA since the port is closed in your router.

RGN01 · March 6, 2021, 10:12am

There is no cure for stupid!

But - and this is the key point - if someone does turn off a control that the HASS team put in place as a default, they take full responsibility! It’s kinda like blaming a car manufacturer for a fatality when the driver clipped the belt then sat on it! It would be ludicrous!

samnewman86 · March 6, 2021, 10:47am

There are two workarounds for disabling the password check. One equivalent to plugging the belt in and sitting on it and one equivalent to removing the belt altogether.
They are both easy to implement for any one with the knowledge needed to use bad passwords safely

RGN01 · March 6, 2021, 12:02pm

No, you are conflating an ability to secure a network with a current ability to understand YAML and the inner workings of HASS. These are absolutely not the same thing so it is an invalid comparison, serving only as an effort to make others feel inferior!

If it is so easy, why not detail the two options for those that are not masters of HASS but are increasingly frustrated by this approach that is akin to adding spikes into the driver’s seat that intermittently punch his backside even after he removed the fuse from the operating mechanism?

code-in-progress · March 6, 2021, 12:17pm

Mosquitto (which is the default MQTT broker add-on), does not support account locking. There is no mechanism built into it for that. One could literally brute force most MQTT servers until the end of time without restriction. IIRC, only HiveMQ and VerneMQ support account locking and/or support for something like fail2ban.

samnewman86 · March 6, 2021, 12:21pm

Both solutions, blocking the API in your firewall, and automations to dismiss the notifications are both on the forum already.

maxym · March 6, 2021, 12:24pm

Few minutes ago I come to another conclusion.
Besides of technical/technological-wise motivations there is what is happening:

the changes haven’t been discussed with community (I’m not aware of it, but it’s my guess seeing the reaction of the community
the changes have been implemented without information shared prior to this fact, which could make us better prepared for that
devs left us alone with the problem, letting some unauthorized forum users to defend development decisions. It leads to unnecessary flame wars and obviously solves nothing.
If you track posts other than flame ones, you can see that setting more secure passwords don’t always work. And again: no support from devs. Community members try to help, but at some point they cannot help anymore.

In other words, putting motivations aside, the whole transition is not executed properly. Maybe improvement in transparency and execution areas could help more, even in case that we cannot agree with particular feature. But at least it would not compromise reliability of our systems.

code-in-progress · March 6, 2021, 12:34pm

Correct. I scoured the forums here, Reddit and the github site and nowhere did I see where this feature was requested and/or discussed.

That’s also correct. The pr was done 10 days ago with no discussion with anyone outside of the devs: Add check for pwned secrets to resolution center by pvizeli · Pull Request #2614 · home-assistant/supervisor · GitHub

I get that it’s their project and we are merely consumers of it, but something like this should have had an prior announcement or even some sort of beta testing. A pull from less than 2 weeks ago seems awfully rushed to me.

RGN01 · March 6, 2021, 12:38pm

I have done both of those - the api is blocked and the attempts show in the firewall logs as blocked. The system logs confirm this.

I have also made the changes to the config.yaml file, too and the alerts STILL continue.

I have now added an automation to remove the alerts but this is, frankly, ludicrous when all that is needed is a button with a few warnings about taking your life into your own hands if you disable the alerts!

RGN01 · March 6, 2021, 12:46pm

However complex the process of disabling this check (NOTE: it is the check that I want to stop, not only the alert) actually is, is it too much to ask for it to be documented - and the change communicated - in advance of springing this on the community?

finity · March 7, 2021, 12:13am

Yes.

It happens on a surprisingly fairly regular basis.

The devs make a decision, tell nobody, people notice because it starts impacting them, there’s a big uproar, they and others start circling the wagons (“stop complaining”, “it’s free so you get what you pay for”, “if you don’t like it submit a PR” (that gets tossed immediately…), “what have YOU done to support HA lately?”, etc, etc).

Most of the time the issue gets ignored and people end up just having to live with it and/or do workarounds to get the exact same functionality back as there was before. So it completely thwarts any “benefit” that they think the change bestowed so all it did was cause a bunch of drama for nothing.

Occasionally (a la Supervised installs) the devs figure out people aren’t happy, undo the change and vow to do better next time communicating changes to the users. Until there is a next time and the cycle continues…

John_P · March 7, 2021, 6:00am

After clicking away the hourly password notification some days I went back to a previous version. No updates anymore on my local lan for now.

John_P · March 7, 2021, 1:27pm

I don’t have a secrets.yaml, and still this notification every hour.

code-in-progress · March 7, 2021, 2:16pm

secrets.yaml is not a requirement. What the add-on does is parses secrets (aka passwords) in any of the configuration and/or add-on configurations.

123 · March 7, 2021, 2:19pm

FYI

Earlier I mentioned blocking api.pwnedpasswords.com but I’ve now switched to another method. Instead of blocking access I modified the code so it suppresses the request to api.pwnedpasswords.com.

github.com

home-assistant/supervisor/blob/05e3d3b7796fccd8ea210cba4f88c8ef5d703c6a/supervisor/utils/pwned.py#L11


      
          """Small wrapper for haveibeenpwned.com API."""
          import asyncio
          import io
          import logging
          
          import aiohttp
          
          from ..exceptions import PwnedConnectivityError, PwnedError
          
          _LOGGER: logging.Logger = logging.getLogger(__name__)
          _API_CALL = "https://api.pwnedpasswords.com/range/{hash}"
          
          
          async def check_pwned_password(websession: aiohttp.ClientSession, sha1_pw: str) -> bool:
              """Check if password is pwned."""
              sha1_pw = sha1_pw.upper()
              try:
                  async with websession.get(
                      _API_CALL.format(hash=sha1_pw[:5]), timeout=aiohttp.ClientTimeout(total=10)
                  ) as request:
                      if request.status != 200:

I changed the line to:

_API_CALL = "https://127.0.0.1/range/{hash}"

Restart Supervisor and it no longer makes the request to the external URL. This method provides the following benefits:

No log message in PiHole indicating the request was blocked.
No log message in Supervisor indicating it couldn’t access the URL.

The drawback is that code modifications are undone the moment Supervisor is upgraded. To make things easier, I’ve created a shell script to perform the code modification. FWIW, the same script is also used to ‘patch’ some other code as well (throttle the frequent requests to version.home-assistant.io).

code-in-progress · March 7, 2021, 2:23pm

I blocked it at my firewall as I know that other things like password managers (1password, in particular) are using this same method. Since I really don’t want to use HIBP in any way, shape or form outside of my own checking, I decided to just block it at the firewall level and be done with it.

maxym · March 7, 2021, 2:48pm

I can see the next step: to prepare merge request with removed
check_pwned_password method call. Who knows, maybe someone will accepted it…

thepedro · March 7, 2021, 3:08pm

I don’t want hassio send my passwords, my password hashes or part of them to anybody!
If someone will expoit pwnedpasswords.com they will know that at my IP address has wake password associated. Not so cyber safe!
Please make this feature configurable!