Exactly, and to top it off HA stores passwords in plain text (which I totally understand).
So as soon as anyone got in to my HA then my unsafe node red password is irrelevant anyway.
4 Likes
im on a knife edge about abandoning HA all together
between the problem of it constantly locking me out of my amazon account, crashing for no apparent reason, and now this…
75% of my smart stuff has been removed last weekend due to how often it wont work because of HA issues, and i only started with it all 6 months ago
This is a TERRIBLY implemented and half-baked feature.
Yes, weak passwords are bad, and nobody should use them. However, there are times when a particular password is weak for a reason. There are even times when there is a reason to not change a password that is known to be compromised.
More importantly, these notifications are not helpful. For some, it can be clear where and what the offending password is, for others, it’s a complete mystery. I get constant notifications about core_ssh.
As far as I know, there is no core_ssh. There’s HA Core, and there’s the SSH and Terminal addon I have installed, but I have no idea what core_ssh is, where it is, or what password is supposedly pwned. There’s a link to an explanation of what a compromised password is, just in case I’ve been living in a cave since the 90’s, but that’s it.
No direction. No useful links. No action suggestions, just a “hey, you’ve got a mystery password that sucks somewhere. Go find it and try to suck less.”
We need to be able to turn this off, and it needs to be turned off for everyone until it is fully function. In it’s current state, it is much more annoying than helpful.
16 Likes
Why would being on the lan give them access to your config? That’s a bit of a leap. A weak password in ha could help to bridge that gap.
So a chrome extension (or mobile app) is updated with malicious code. Before this is reported and you can delete it is scans your network, tries common passwords on your samba shares. Like Hass/Hass admin/admin, then it has access to your config and all your passwords for online services.
Then it has access to your config, and all your complex passwords for online services etc.
heres a wild idea, i dont know if its ever been tried before on any other equipment for any other reasons though /sarcasm
keep passwords in a compiled .pyc file
theyre entered as normal text, then a forced restart puts them into a file thats compiled garbage (yes, i know they can be decompiled, but, theyre no longer plain text)
1 Like
I think something like this is on the radar… frenck talked about it with the 2021.2 blog post I think. I know it’s something they are considering how to solve. Link to discussion here Managing secrets - #2 by frenck
I actually said if they were on the lan AND have access, but anyway…
The post I was replying to specifically mentioned addons and custom components. An addon has access to your homeassistant file system, and custom components do too. In fact, we just had 2 security bulletins because an attacker could use custom components to access your secrets file over the internet without even knowing your login password. These warnings would not have prevented that attack vector, and it is still open because the only custom components that are ‘fixed’ are the ones where the vulnerability was found. Yes you’ll get a warning in your log when someone does it nowadays, but it’s probably too late by then.
If someone has managed to physically get a malicious device on to your LAN, then it’s not a leap that they would be able to access your homeassistant at all, it’s just a matter of time. In fact, if someone is installing devices on your LAN you have much bigger problems because the attacker had upped the ante quite significantly.
I didn’t mention chrome extensions at all. But let’s say that is the attack vector and they discover your mqtt broker has user/pass rather than something ‘strong and secure’ and sends that back to the farm before you plug the hole - if the mqtt broker is only accessible by LAN, plugging the hole has fixed the vulnerability, changing the password is still irrelevant.
There’s also the irony that someone pointed out above that in order to generate this warning, the homeassistant supervisor is sending personal information out on to the internet without permission, and is then lecturing people on security. The mind boggles.
13 Likes
I get the point of good passwords and OK fine I will comply but how do I fix node red? I changed both the http_node: and http_static: passwords in the node red config but it is still bitching about me being pwned. WTH?
Do I have to go by this brutally complex process? https://nodered.org/docs/user-guide/runtime/securing-node-red
3 Likes
Hi there
Thanks for the automation. I tried to create a new automation and add the code via YAML. Unfortunately I get this error: message malformed: expected dictionary.
Do I have to add template-sensors or reformat the code? Sorry I rarely work with automations and have little knowledge how to configure them.
I copied the code and inserted it like below:
- alias: persistent_notification_clear_pwned
mode: parallel
trigger:
- platform: event
event_type: call_service
event_data:
domain: persistent_notification
service: create
condition:
- condition: template
value_template: >
{{ 'supervisor_issue_pwned' in trigger.event.data.service_data.notification_id }}
action:
- service: persistent_notification.dismiss
data:
notification_id: >
{{ trigger.event.data.service_data.notification_id }}
# Remove this after testing :-)
- service: persistent_notification.create
data:
title: Dismissed notification
message: >
{{ trigger.event.data.service_data.notification_id }}
All the best
Andrew
“5EFeqUYm8VQdHp” offers no more security than “password” because I have configured HA to be wide open by setting my home network in trusted_networks, so my config is visible to anybody local.
I don’t need to be notified of my weak password repeatedly, nor to I need the false security offered by the message disappearing when I change my password to something complex.
5 Likes
Remove the hyphen and move all to the left in the UI yaml editor.
There is an option in NodeRed to disable the password warning notification. Add this to your NodeRed config:
i_like_to_be_pwned: true
The notification demands a stronger password but the NodeRed documentation warns against changing your password:
Option: credential_secret
Credentials are encrypted by Node-RED in storage, using a secret key. This option allows you to specify your secret key. This can be anything you like, it is just like a password. Be sure to store it somewhere safe. You might need it in the future! (e.g., When restoring a backup).
“Note : Once you set this property, do not change it - doing so will prevent Node-RED from being able to decrypt your existing credentials and they will be lost.”
UPDATE: The NodeRed config option I pasted above does not seem to prevent the notification nag about the password.
1 Like
I can’t understand, why Supervisor started to send my passwords to a third party without my consent and any further notification. That is a data breach that should be stated on https://alerts.home-assistant.io/.
If that would have been a HA feature for example, I would know about it before from the release notes, I could avoid that update.
Supervisor is however auto updated and there is no way I know of to opt-out.
Imagine a worst-case, a failure in the implementation where Supervisor would send thousands of passwords unhashed to a third party…
12 Likes
Tried it as well, but got some errors in the log file, see below. What’s wrong with the trigger so far, any idea?? Thanks
Logger: homeassistant.components.automation.notification_delete_pwned_notifications
Source: components/automation/__init__.py:408
Integration: Automatisierung (documentation, issues)
First occurred: 10:44:09 (2 occurrences)
Last logged: 10:44:37
Error while executing automation automation.notification_delete_pwned_notifications: Error rendering data template: UndefinedError: 'trigger' is undefined
Did you run the action manually?
yes, ok just got it - when manually started the trigger is not correct. My fault - thanks!
1 Like
If you want to trigger the automation you can create a persistent notification in Dev Tools/services with notification_id: supervisor_issue_pwned
@jaaem & @VDRainer thanks for the dismissal, nice and neat.
Saved me time in writting one for myself 
First, I was looking at the logs this morning and watching all the notifications the automation above killed. (Thanks!!) They are coming once ever hour! This is even more absurd than I thought. Totally unjustifiable by any stretch.
I think I understand what you’re saying here, please correct me if I’m wrong.But it seems to me a bit of a leap.
In your (completely plausible) scenario, some device on my LAN is hacked and goes looking for SAMBA shares. Well, first of all, it can only hack another device which supports the SAMBA protocol, and I personally only have a very few of those. But yes, HA is one of them.
I don’t use easy credentials like Hass/Hass or admin/admin.
OK, so let’s stipulate that it has a sophisticated algorithm (and lots of processing power available - another leap) and it starts using pwned passwords it finds in the HIBP database.
Now it has another problem. Which account to use? Obviously start with admin, hass, or other easy ones. But there are an almost infinite number of possible combinations between “easy” user accounts and every pwned password in the database.
I don’t use “easy” user accounts. So it’s never going to succeed. Furthermore, I don’t use “easy” passwords like admin or hass.
Suppose I use a random, 16-character password that just happens to be in the pwned database for whatever reason. Who cares? No device on my LAN has the processing power to guess which user account and password combination to use, out of an infinite number of possibilities. Even if it starts with the enormous list of pwned passwords.
5 Likes
At first, no application should know a password once it’s stored. Then no application should behave like it knows your original password - this is speaking about reputation.
All systemsI know check strenght of password when entering it. I’ve seen no system which ckecks passwords retrospectively. THIS would be considered the bad practice.
BTW how HA identify weak/pwned passwords? I hope it doesn’t send them to 3rd party services
Edit: f** it’s already happening? really? Lol, what reputation we are talking about?
6 Likes