It’s the best and only viable excuse! It is only local, it is only a few “mqtt” talkers which I try to avoid… (I do not like mqtt in that sense).
But agree, that is not the point of my question… so, having a user in homeassistant has nothing to do to talk to mqtt, only the other way around, mqtt uses the users in home assistant to validate against.
Correct?
So the mqtt integration does not rely on any of these “users”?
Thank you for taking the time to respond!
This mqtt add-on does, yes.
Notifications dismissed and then restarted.
Now the supervisor log shows the skipping, but the notification constantly reappears (the latest 18 min ago, currently it’s 16:25 GMT+1 in the afternoon).
21-03-16 14:04:59 INFO (MainThread) [supervisor.homeassistant.api] Updated Home Assistant API token
21-03-16 15:04:59 INFO (MainThread) [supervisor.resolution.check] Starting system checks with state CoreState.RUNNING
21-03-16 15:04:59 WARNING (MainThread) [supervisor.resolution.check] Skipping disabled check addon_pwned
21-03-16 15:04:59 INFO (MainThread) [supervisor.resolution.checks.base] Run check for IssueType.FREE_SPACE/ContextType.SYSTEM
21-03-16 15:04:59 INFO (MainThread) [supervisor.resolution.checks.base] Run check for IssueType.SECURITY/ContextType.CORE
21-03-16 15:04:59 INFO (MainThread) [supervisor.resolution.check] System checks complete
21-03-16 15:04:59 INFO (MainThread) [supervisor.resolution.fixup] Starting system autofix at state CoreState.RUNNING
21-03-16 15:04:59 INFO (MainThread) [supervisor.resolution.fixup] System autofix complete
21-03-16 15:04:59 INFO (MainThread) [supervisor.homeassistant.api] Updated Home Assistant API token
21-03-16 15:18:29 INFO (MainThread) [supervisor.host.info] Updating local host information
21-03-16 15:18:29 INFO (MainThread) [supervisor.host.services] Updating service information
21-03-16 15:18:29 INFO (MainThread) [supervisor.host.network] Updating local network information
21-03-16 15:18:30 INFO (MainThread) [supervisor.host.sound] Updating PulseAudio information
21-03-16 15:18:30 INFO (MainThread) [supervisor.host] Host information reload completed
I rebooted to make sure everything involved was restarted. If you’re only restarting HA then maybe that’s it.
Good suggestion! 
This solved the problem. 
I made a full shutdown and reboot of my machine and now after 3 hours no more notifications!
Thanks!
Considering the LastPass hack of late, the fact that most users choose crappy passwords, I must disagree that the checking of passwords should be allowed to be-opt out.
There are tons of free and low-cost services available to at least do basic validation against bad passwords. Even some password component checking (without validating anything against a third party (which can be done securely), can be done internally.
An example is the AADPP (Azure AD Password Protection) function for Active Directory. This enable an AD forest to validate a password when changed by the user against a global list of bad password and an algorithm that breaks down the password to its smallest components.
The password is never sent across the wire, but check within the change password entity. If the password (via its hash) achieves the minimum required points, it is allowed. If not, then changing to that password is prevented.
Users will opt-out when given the choice to make it “easier”. As a result, making it less secure. That lower security threatens the longevity of HA when it begins to create a narrative of less secure.
The secrets.yaml should be eliminated and its contents moved to an encrypted key store or secret store within HA. The fact that it is plain text does little, if anything, for security.
When anyone can gain some basic access to the config filesystem, not having those in the configuration.yaml, does very little to slow anyone down.
HA can’t enforce password policies for counterparty integrations. So some of the passwords will be crappy even though users wouldn’t want to. This goes especially for numerical PIN-codes.
For example:
As you can imagine, a SHA1 hash-registry for PIN-codes would be very short and even though with only the first five in a K-anonymity check, you would fairly quickly find out the PIN. With the circumstances of HIBP is not a service by HA, but a third party, any changes to it could result in easy access to PIN and IP.
Secondary, some users do have bad passwords and will/can not change them. Throwing them infront of the bus will hardly do HA any service?
Perhaps you miss the point. The password that a user choose for accessing HA is different than a password used for enabling a cloud based integration. A password policy would have nothing to do with an integration password, because those passwords are not maintained by HA itself.
Keep in mind, that there are tons of cloud based solutions that have stronger security. For example, the Google Nest thermostat integration. The users password is illrelevant, and whether it is weak or not, isn’t even used in the integration. the setup requires the user to access the google developers console. Google already requires MFA of all users. The authentication for HA to a nest thermostat is via Client ID/Secret and is generated, the user doesn’t create it. Therefore, there would not be a weak password used, even in such a case where the users own Google password was considered relatively weak.
IIRC the password check currently including all provided passwords.
Not just accessing HA, but also HA <-> integration. While Google Nest is done with a private key, a lot of integrations still use plain vanilla passwords or even PIN. It’s not about integrations with strength, but rather those with weakness. And since HA can’t enforce password policies on those, I think it should be opted if those should be sent to HIBP.
I think it would be overreaching to ask HA to enforce password policies that includes third parties.
Keep in mind, that without some type of multi-factor auth, client id and client secret, is just new names for username and password.
Yes, there are services that must be able to login, those should be offered with cert based auth. Most don’t offer that. The whole notion of Client_ID and Client)Secret is the ID and password are typically much longer, and the user ID is only good for one thing. Typical users, have terrible passwords, reuse them on many sites, and the usernames are relatively short. Still, it is just username and password.
Username and password authentication needs to die and needed to do so 10+ years ago.
It is possible to have a service account with MFA level creds (something your are=userid, something you know=secret, password, etc., something you have=hardware specific key, similar to a hardware token.) Hardware tokens are difficult to replicate or copy, making it too difficult for most hackers outside of being state sponsored.
Enforcing a password policy that disallows the use of passwords from prior breaches, using a username or personal information in the password if perfectly acceptable. It just isn’t a standard that everyone is used to.
No it’s not. It is not the job of locally installed productivity software to police the password habbits of its users.
If I choose to use a password of 1234 or even no password at all, might it be because I am stupid or because I have my reasons (locally isolated network), then this is entiry my choice and responsibity. HA, or any other locally installed software for that matter, has no business in second guessing, checking, vetting, refusing or lecturing a user about his choice of password or credentials. Its job is to provide the functionality it was designed for. Not to be an ideology police trying to ‘save the users from themselves’.
My point is not technical.