Well if it’s Google, you’d only have to wait a year or so until they drop the feature completely.
3 Likes
Perimeter security is the idea that you have trustworthy networks and less trustworthy networks (like the Internet) and that you put a firewall between these and then your trustworthy networks are safe from the less trustworthy networks.
But why do you put a firewall between these? Because clients in that trustworthy networks need to communicate with servers in the less trustworthy networks or you even poke holes in that firewall to allow very specific communication from clients in the less trustworthy networks to servers in your trustworthy networks. So in fact you have the less trustworthy networks in your trustworthy networks and that means that you should not trust something just because its IP address is from your trustworthy network because the less trustworthy networks can execute code in your trustworthy networks. Intentionally, because of some misconfiguration (Hi X-Forwarded-For) or because of some unpatched vulnerability in one of the systems operating in your trustworthy network.
You should instead require strong authentication and you need to transfer data only in encrypted form. Like you would do when you communicate over an untrustworthy network like the internet.
1 Like
Perimeter security is also just a ring of security where best practice is security in depth.
A perimeter security in the physical form would be a fence around your house, but security in depth would then add guard dogs behind the fence, a lock on the door and. Burglar alarm inside.
1 Like
TL;DR: Run each single system as if it had a public IP on the internet.
4 Likes
@nohn: I think your discussion is away from what was going wrong. But maybe I’m wrong. If I understood it right, the problem is that the configuration of the proxy settings was done in a way the system was not able to differentiate between internal and external access. Even if you have a firewall in place this would not help in such a case! @all: I’ve both two factor authentication and firewall, but I’m still not happy with the security options in HA. Main problem is how to factor authentication is implemented. You have to enable it per user, after the user is configured. This is in my opinion not aligned with the zero trust model architecture I would recommend for HA. Zero trust means, nothing is allowed until you explicitly allow it.
1 Like
The topmost feature request that I’d like to see implemented is Role Based Access Control between users and entities.
4 Likes
Completely agree.
Problem is that I (and others) have to leave an open door for, e.g., Google Assistant. Arguably, not necessary when Voice Assistant will be fully mature, but still needed today…
Now, they don’t need access to the UI… 
If someone had the same idea and has nginx rules allowing only api and no UI, you’re welcome 
1 Like
This is the default type of response from the devs, and it’s really starting to piss me off.
Options? We don’t believe in giving options.
We made a mistake? No, you’re using it wrong.
4 Likes
For a reason. They are a small team and want to limit what they support. And they do give us quite a few options, just not for everything.
In this case that’s actually true.
2 Likes
got to be honest there now Tom, maybe only in the case of an incorrectly configured remote acces config.
The local show-all though is a privacy concern too. And was form over function. Glad it was revoked
3 Likes
Correct.
If someone untrusted has access to your local network you have bigger issues than them knowing your profile name.
7 Likes
sure, but that is besides the point.
Why not just be glad it was a mistake and the dev team admits as such. I am.
btw, its not so much untrusted users I am (you now made me ) worried about, it’s all a matter of privacy. And roles. Just dont open everyone up.
It is, so couldn’t we just be given the option to use it? The old one and the new one are already in, and were planned to be supported, but the users seemingly need the devs to babysit what they can and can’t use when the devs for once actually listen to user concerns.
Read the sentences above that bit you quoted.
I’m going to share something that this incident caused me to remember: it was a series of interactions with the core developers that, if Nabu Casa wants to go mainstream they will have to deal with.
EDIT: I’ve learned that I wasn’t interacting with core developers. I thought I was and I was wrong.
There is a fair number of core developers that do not share a philosophical view of security that is shared in the United States among technology professionals. I can’t call it wrong. I just call it, difference of culture in what is acceptable and not acceptable.
In several interactions on the HA Discord, I was asking how to lock down certain parts of my Home Assistant installation. I had one and then another developer in separate interactions say, “Oh, you’re one of those users.” Meaning that being concerned about security was just paranoia and I was being concerned about something that didn’t matter that much relative to being concerned with “real security”.
In one instance I was trying to ensure that Home Assistant was running on a IoT VLAN instead of the same VLAN as my computers. The concept is simple: IoT devices can be used as attack vectors to sniff network traffic or attack other devices on the network. This includes all of the WiFi switches and cameras being used to attack HA itself. I was basically being told I was being paranoid instead of actually guarding against real threats.
EDIT: I wasn’t very clear here. It wasn’t just about VLANs, it was also about how the Proxy Server works, which are two different things. The last statement is true nonetheless. And here’s the thing: we should all get that in maker space there is inherent risk. Most IoT devices are insecure and come with risk. That shouldn’t mean we should dismiss that risk and not be vigilant.
So when the new login screen came along, and I saw that you didn’t have to authenticate yourself if you were on the local network, I knew where that mindset was coming from. It’s a culture of acceptance of lack of privacy. Or your could say it’s the acknowledgment that privacy doesn’t exist so why bother. Or said more explicitly, in my country privacy is mandated by the government so I don’t have to worry about it, and I’m choosing to ignore that devices made in other countries may not honor my country’s regulations.
Either way you phrase it, it’s just bad cybersecurity. And yes, Nabu Casa has implemented better cyber audits for vulnerabilities in the code, but there is no way to deal with a cultural issue that creates secure code with open door means of extracting data.
Now, you could say, what use is home automation data? Besides being able to profile when people are home vs. not home for casing a home for a burglary (Which is not likely to happen, btw.), the most obvious is that the plug-ins we are adding to HA go well beyond home automation and fall into the realm of personal assistant, with financial and health privacy implications.
Nabu Casa needs to wake up and start focusing on real security by design. It should self-configure certificate renewal and proxy servers. It should force all traffic through authenticated TLS endpoints, or should warn the user that an integration is communicating in an insecure manner with instructions on how to secure the communication. And yes… that could mean changing out one IoT for another because the IoT device manufacturer doesn’t believe in security either.
Finally, there is a feature request that is emerging in this event: when an HA instance connects to an IoT or integration, it should first check if there are any open CVE alerts for that device and the device’s firmware version.
I’m curious what others think.
4 Likes
If someone untrusted has access to your local network you have bigger issues than them knowing your profile name.
I’m going to be terse here because your comment warrants it: This is garbage logic. It is called a Red Herring plus a Strawman logical fallacy.
Yes, the statement is true. If you have an unauthorized person on your local network you have bigger problems.
While it is true, that doesn’t excuse insecure by design architecture.
The correct best practice from NIST and Secure Code principles is to ASSUME there will always be a bad actor on my local network. FWIW: I have three… Amazon, Google, Tuya. I’m starting to think I have four, the above plus Home Assistant.
All devices should require authentication and authorization by default, and should have all communications secure over encrypted ports by default. (HTTPS/TLS or SSH)
This is an area that Home Assistant need to stop and work on if it ever wants to be considered everyday users instead of makers and enthusiasts.
10 Likes
Here’s something to ponder: How many actual serious security breaches have ever occurred to home assistant users (that weren’t blatant stupidity on the user’s part)?
One that I know of (the SSH UPnP thing). That was fixed many years ago.
So IMHO, you are being overly paranoid.
It is secure enough for now. And continues to get better. The sky isn’t falling.
1 Like
The core developers did not say this to you. You were talking to other community members, volunteers.
I could name names but that isn’t the point.
By all means, DM me a link. I think you may be mistaking who does/doesn’t work for Nabu Casa.