I’m also one of the people that encountered the new welcome page presented publicly. At first, i thought Nabu had broken something, but after a lot of digging, I found it wasn’t their fault at all. As an “IT guy,” I’m embarrassed to say I had nginx proxy manager incorrectly configured.
If you’re using their new “stream” function to redirect the port number, don’t. Use the server block to change the listen port. This way, the x-forwarded-for variable is passed properly.
In the long run, I really appreciate that you guys did it, and hope the work that went into the new page does not go to waste.
Apple’s OSes and Microsoft’s Windows will show user profiles on the login page, but only on the local console.
Any network service will require a typed username.
I’d much sooner rather see the implementation of PassKey to be able to eliminate usernames, passwords and 2FA codes entirely. GitHub does this exceptionally well.
As others already said, if someone accessed my lan I have a bigger problem than exposing home assistant usernames.
That said, obviously usernames must be exposed only in lan and not outside due to a misconfigured proxy (the thing that must be fixed).
What i would like to understand is if this is happening only when the users had duckdns (or other unofficial external access) setup, or also if they were using nabu casa.
The only way the information was accessible from outside the home network was if the user had opened external access through a proxy and he had not setup the proxy to pass to HA the real external client IP. Many proxies by default will instead present themselves to HA as the client with a local IP.
But that is not really the definition of mainstream, is it? I would say it is more mainstream to go with the path of least resistance.
As Home Assistant is targeting more and more “Regular” and “Non-technical” users, transitioning away from their former USP where everything were configurable in code (yaml) and you could version all your config in git, to a “drag and drop” user interface with only basic functionality and large icons, you cannot assume that those people know what they’re doing.
Mainstream or not; if the average user simply want to get rid of that annoying insecure-website-warning and want a proper certificate. They google something related to https and end up at some inofficial guide of how to set up NginX without having a clue of what they are doing, what X-Forwarded-For header is about, or even what headers or reverse proxies are. That is your target audience right there. Even if it would be great, you cannot assume they know what they’re doing.
I’m mostly familiar with Apple, but they only expose these details if you’re physically there. I.e. watching the laptop screen. It is not presented that way over the network, not even to the local network.
You should never trust your local network to be secure.
A suggested workaround would be to enable this “display of all users”-login screen only after the user has initially authenticated (and then perhaps logs out) using a cookie or similar. Just like a “remember my username”-thingy. Upon successful login, you’re simply presented with a question like “Is this device trusted, and should show all the users on the login screen?” (followed by a warning: do not do this on a public computer). If the user agrees, then place a cookie with an access token so that the user, next time, on that physical device, would have access to load the current users on the login screen. Or perhaps even the list of current users, at the time, and simply only refresh this information for the device once a user is actaully logged in. It is not perfect, but far more secure than assuming. And this would not leak information to any device that has not already authenticated. And, of course, only enable this feature over https.
My instance isn’t even accesible remotely and I prefer the old login method. Because it is much quicker and easier with a browser with password manager. To me, having the option to choose between login methods seems the most reasonable. With a warning about security implications to educate users.
I am one of those users who setup a reverse proxy and my own DNS server to access HA from everywhere.
I always use the domain to open HA - and never got the new Login, even within my local network - except, when I used the local IP.
So I guess, my proxy settings are at least ‘secure’ - maybe not correct, but at least it did not expose user names to external networks.
I am also using another application - emby, which is using similar login methods…
There, you can choose on a User level, if you want to show the user name - or not:
I think, such a setting would be OK - but the team should provide a documentation on how to configure your reverse-proxy correctly - Then, it is completely the users / admins fault if they do not follow the documentation and expose sensitive data to external networks.
It is not only the “leaking information to the internet” thing. It is also what happens in the internal network. If you have a 1-click sign in, it can pose a few other problems as well.
Lets take an example where you have a tablet on the wall to control your home assistant. You set up a user (not an administrator) for it and you sign in. Anyone can log of and be presented with the 1-click sign in page. They can then login with the administrator account and change anything they want.
Even if it’s just your teenage son that messes with the tablet (and therefore considered safe / secure) it’s something that you don’t want…
Surprised to see people only talking about remote login.
I have nothing of the sort, and found it rather an unpleasant surprise to see that when opening the app, anyone of my registered users could simply select my user account. Ofc they’d still need my PW, (that is, if I didnt have trusted_networks enabled), but still.
Others compare it to Netflix…
and yes, even there I find it compromising that anyone can select anyone else’s profile and check what they have been watching.
Its a whole other matter on our Home Assistant systems though.
So, I am really glad the shiny (form over function) new logon screen is taken out now, and I do hope that any future system will also mind the local privacy/security concern.
And always use an opt-in, by default these options ought to be ‘off’. Unless we’re talking security settings ofc, in which it should be the other way around obviously.
For whatever (bad) reason, I have port forwarding rather than reverse proxy, so no “forwarder_for” to distinguish internal/external, here.
I thought: “No problem, we have internal/external url in configuration.yaml exactly for that”, but that didn’t seem to work, either: the list of users was still presented.
So what would have been to proper configuration to not have the list of users presented on port forwarded instances?
I have a standard Hassio install, I have never touched the proxy settings in configuration.yaml for not wanting to break anything. My instance is internet accessible via the Cloudflared add-on and a Cloudflare Tunnel.
Again, I have never touched this, this is how it came after installing Hassio. Please could someone who knows better confirm this is configured “correctly” in the context of this thread or point me to a guide about how these SHOULD be set? I notice in the http integration page, use_x_forwarded_for is false by default.
If there is a possibility uninformed users (like myself) have misconfigured proxies, there should be reference for what is correct IMO.
It’s hard to argue it’s not mainstream given the volume impacted warrants a specific code change to make users aware… if it gives rise to that quantum of people, like it or not, it’s mainstream
OMG, “misconfigured” reverse proxies (which might actually genuinely not be a problem, if the service behind isn’t supposed to make decisions based on client IP) are so common, and this issue should have been so obvious to the devs!
FWIW, people don’t get hired for simple web dev (not security expert) positions for WAY less obvious mistakes.
Then again, if the manufacturer suddenly makes my door mat transparent, then that’s by no means my fault, yet it exposes the hiding place of my spare key.
No reason to believe it’s not however I also lack the understanding of what these config options do and how they SHOULD be configured to know that it is right. It would be particularly alarming in my case if they were wrong as, like I say, I’ve not touched them from default.
Thanks for checking it. Is there any best practice document for how these should be configured? Perhaps the answer is as simple as not fiddling if you don’t understand.
