That is not true. I understand from this statement that you are implying that we don’t have to put password in the CLI because it’s useless without physical security, but that is false. Again, we need to have a Defense in Depth approach and apply layers of remediation’s to different risks. Physical security is one area that comes with multiple risks and they are not all of the same criticality.
For example, assuming physical access, bypassing bitlocker with TPM and a pin (2 factor authentication) would be a risk a lot lower than not having bitlocker at all. I have one bypass in mind and I challenge you to find it: how would you bypass bitlocker with TPM and a pin, assuming physical access?
I would agree, we can’t rely on one layer of security (physical). There should be multiple as Tristan suggests. Again, this would never fly in a IT environment. Do you think servers in a data center are all open on the console with no passwords since they are in a locked room? No way man.
This is such a basic OS function, the amount of time we are spending debating its usefulness, it could already be implemented.
So I’ve been sat here looking at all the arguements as to why there is need to put in functionality in to provide a mechanism for setting a console password. And I’ve been laughing… The reason, I’ve worked in Cyber Security for over 20 years, I’ve been a Penetration Tester, Application Security Consultant, Network Security Architect, Application Security Architect, CISO and a CTO. I heard everyone of these arguements for not putting in it about 1000+ times over the years for then have everyone one of them disproved. Now I’m going to give you a practical example of a time from about 2005 when I heard this arguement from a large telco equipment manuacturer who was using the very same arguement when it came to putting a console password on the console for the small embedded linux system that was running on the microcell for 4G.
It took me less tha 5 mins to defeat the security of the metal case + anti-tamper features they used to prevent access to the network port on the front of the unit that would give you serial console to the device. From there onto the console, without a password… Now what could you from that console… Well using the installed scp I copied on some tools and within 20 mins I’d was was in the possition I could shut down a 3rd of the countries cell network.
Security is about delaying the inevitable, not stopping access but delaying access, the longer it takes for something to happen the better, because it enables you to detect it before it happens. Consider this, the HassOS operates akin to something like VMWare ESX, you will never see an ESX server running without a host console login prompt, because you control the host you control the guests. Some applies here, doesn’t matter what you do to secure the network visible parts of HA because the security of the entire platform relies on the host being secure and it it’s current format it is as far from being a secure host as that microcell was in 2005.
The point I found that issue in 2005, that microcell hardware had been rolled out globally, within 24 hours of that demonstration, every one of those microcells had a console password.
I’m half tempted to put the CVE in now for the unsecured console access for HassOS…
I just want to beat this seemingly dead horse with two quick additions:
A CLI password would be a good, basic, child-proofing addition. Your threat doesn’t have to be someone breaking in and trying to steal your Google/Spotify/… password.
The lack of encryption bothered me since the day I started messing with Home Assistant. I wanted to use the HAOS image for its tight integration and OTA updates, but I did not want to expose secrets and some of the logged data. In my case, it is not a simple child-proofing concern.
I also wanted to run HAOS on a low power IPC/ThinClient. The solution I went with - and this may not work for everyone - is: a generic debian install with FDE, convert the debian install to Proxmox, and deploy HAOS to proxmox as a VM. This way I can run HAOS on a super low power device, while securing its storage to within my comfort zone.
In terms of where to store your keys, how to deal with unlocking the hypervisor, and related stuff, there are lots of options. Since Proxmox runs on debian, you get quite a lot of flexibility (Use TPM for storing the FDE keys? Sure. / Remote unlock? Sure. Manually type a LUKS key via TTY on each reboot? Whatever floats your boat.)
Goodness. This was a sad read. First Google result for “home assistant console password”.
(pre-post edit: removing the rant and installing Proxmox or something)
There is the concept of security in depth to keep in mind. Concepts like disk encryption on top of credentials required on the console would solve the problem. And it would not hurt at all.
The only downside I see is the time spent on something that many people would feel not usable for their use case. Still it’s something worth if an independent developer takes care of that.
How does one get into the console without installing an add-on like the SSH add-on or Studio Code Server? How does one that does not have administrator access do so?
This discussion is specific to the HassOS setup. Getting direct console access is one of the following ways:
Hardware: connect a screen and keyboard to your device. You’ve got console access
VM: Use your VM console
One of the primary reasons for wanting a password on the console is for people (like me) that have HA systems in use at multiple locations. While we can secure the device physically, it’s still a best practice to also ensure that any administrative consoles are secured with some sort of authentication / authorization setup. In this case, a password.
In an attempt to add some clarity (to this long lasting topic).
Maybe it is a difference in perspective, why people see no need for a console password.
I think everyone would agree that access control (password) is a best practice, but that some people just don’t see the need for it.
if HA is ran on a physical device, and if a thieve/hacker has physical access to that device, then indeed the information on the device can be fairly easily accessed, and a password could seem superfluous.
however, if HA is ran on a virtual system, the host could protect that virtual system with disk encryption (and other security measures), which reduces the risk of access to (or theft of) the HA configuration/information on the disk. In that case, additional protection of the console with some sort of authentication/authorization (password) is adding value.
This request is probably supported by people who have already made sure that (offline) access to the file system of the HA box is difficult or impossible. Such setup is common and realistic (e.g. with HA is ran on a VirtualBox).
Both require physical access to the hardware, the availability of additional hardware (keyboard and mouse), and possibly the ability to get past an existing password (in the case of a virtual machine running on a secured server). Can it happen? Sure, but how likely is it that it actually will. Yes, I get that you want to eliminate that last little bit of risk, but most users don’t see the need for it, nor do I think that most users even understand that such things are possible.
Thank you everyone for sharing your input. While there may be differing opinions on this matter, I would still like the feature for myself.
Here are the key points to consider in my eyes:
Defense in depth - security best practices advocate for a multi-layered approach to protect systems and data. By implementing a console password, you add an additional layer of security, even if other security measures are in place.
Risk mitigation - console passwords help mitigate risk, especially in scenarios where physical access is possible. While physical security is a very important aspect, it should be accompanied by authentication mechanisms to deter unauthorized individuals from gaining access to the system.
Accountability - a console password enhances accountability by providing an audit trail of actions performed within the CLI. A password-protected console can help attribute actions to specific a individual.
Delaying unauthorized access - while it’s true that determined attackers MAY find ways to bypass security measures, the goal is to delay unauthorized access as much as possible. By adding a console password, you increase the complexity and time required for an attacker to gain access, which gives you time and data to detect and respond to incidents.
Security best practices - following established security best practices includes implementing authentication mechanisms at all levels of access.
In the end, sure, the decision to implement a password should be based on your own security requirements and your specific use case.
I can’t believe it and it scares me that we have cybersecurity professionals out there advocating against additional security measures, especially when those align with industry accepted best practices.
I like to have an option to enable console authentication too. If you are running a virtual installation of HASIO, for example in ESXI, you don’t need to have physical access to the device to obtain console access.
I’m working with different Virtual Appliances, all of them requires a console authentication, for example pfsense.
Just checking in to register additional concerns over the console not being authenticated. The vnc or equivalent console of any virtual machine will just dump you in a prompt with privileges. The hypervisor “having a password” is just not an acceptable solution, as that implies authorization is not important, which greatly increases the attack surface of the home assistant setup.
Access the vm console itself is generally not behind AAA, just limited to connections from localhost or some network sources in most setups.
This lowers the bar for access from having credentials on the hassos system to executing something as any uid, including unprivileged ones, on the hypervisor, which is much easier to clear.
Not to mention nearly every hypervisor setup has access control of various tiers too, and having this wide open on the console negates these benefits as well.
Dev/moderator seems to strongly feel it is just security theater, which I feel is somewhat (but not entirely) appropriate for a dedicated headless box in your home that can be subverted the second it is touched, but this is not the case for virtual machines as “physical access” is no longer the main barrier.
I would appreciate if you could reconsider since the usage scenarios that the software actively supports has changed.
Ok and what about virtual deployments and secure shell installations in the GUI? They are both very valid deployment scenarios and therefore you should be able to do this. I have this set on both the firewalls I have deployed infront of my home assistant deployment and would very much appreciate this as a secure way to prevent tampering with solar equipment. As changing settings to solar batteries can cause overloading and from what we’ve seen in phones as well as cars, this is a highly dangerous tamepring scenarios and it wouldn’t be much of a smart home if you weren’t able to utilise the power source as part of automation. If you cannot I see OpenHab has the capability so I am sure many will look towards them as the future considering this is not a hard feature to develop:
The real irony is there is a plugin, which anyone can enable via the front end with a simple installation from a repository, so its not actually physical. They’ve allowed there system to access the “physical” port over the http interface. The scary thing is how do you have a smart home if you cannot control the power of the house and since overloading batteries can create a bomb, look at electric cars and phones. So if HA cannot do it their competition can by default, look at OpenHab it has the capability and since HA is on a linux deployment they have developed things with no consideration for security of the underlying system. That means what ever you put on top is not worth anything. You cannot secure the top layers without securing the bottom 1st…
OpenHabs standard documentation for this feature:
I cannot believe this si the case of modern day development and this has been open for over a year…so basically someone who has no network understanding is expected to secure their home how?? What is more important for you, money of development or brand name, as just one hack and you’re going to spend the rest of your careers trying to prove you are secure. You want us to spend money then connecting to your cloud, like hell I will as if this is how secure your onpremise system is I would hate to see how weak your cloud security is.
If by plugin, you are referring to the SSH add-on, that is also enabled by the user, requires user configured option for user/pass authentication or keys, and is running in a container that does not have access to the host system.
Also, a cloud instance is not provided by Nabu Casa. Users and passwords are required there, within HA itself, and MFA is available to be configured for each user. There is no automatic access provided by the cloud service.
