Opt-out of pwned secrets warnings

Configuration
62

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.

63

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
64

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

65

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
66

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
67

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

Bildschirmfoto 2021-03-05 um 08.32.42
Bildschirmfoto 2021-03-05 um 08.32.421308×968 118 KB

68

“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
70

Remove the hyphen and move all to the left in the UI yaml editor.
Auswahl_453

71

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
72

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
73

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
74

Did you run the action manually?

75

yes, ok just got it - when manually started the trigger is not correct. My fault - thanks!

1 Like
76

If you want to trigger the automation you can create a persistent notification in Dev Tools/services with notification_id: supervisor_issue_pwned
Auswahl_455

77

@jaaem & @VDRainer thanks for the dismissal, nice and neat.
Saved me time in writting one for myself :rofl:
:+1:

78

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
79

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
80

I’m afraid I have to agree with OP.

I have plenty enough secure passwords for everything I care about including my samba shares, but who cares if my mqtt broker has “home:automation” set as it’s credentials on it’s own vlan, or my security camera has “all:seeingeye” as it’s credentials, again on the isolated vlan. My HAS password is plenty secure, it’s only accessible via https (it’s not even on the main lan)

I have what I consider to be good general password practices (just ask if the people I annoy at work). I use a private git backed password management tool. But it’s a network in isolation and I really couldn’t care any less about the passwords in it.

Might just patch it out or go back to a version where it didn’t show up, I mean the platform lets me run plugins in unprotected mode, why is it being high and mighty about my passwords? Someone can do far more damage in unprotected mode.

You’re talking to a guy who gets fed up with stupid password rules and proves them useless by sending screen recordings of himself using an ultra secure password that satisfies all their rules “Passw0rd!”

An option is to point dns for api.pwnedpasswords.com to 127.0.0.1

edit: corrected dns domain, thanks Casper

13 Likes
81

That’s why seatbelts are no discussion in some countries when you get pulled over. It doesn’t protect you 100%, but it protects you from full impact.

Not saying this discussion is the same, but it is a choice made by de devs. If you want something else, it’s open source. Go ahead and customize it.

That being said, it should be an option because the consequences are for yourself

1 Like
82

Yeah, but when you buy the car, they don’t let you drive off without a seatbelt and then start the warning a year later.

1 Like