Advice asked: how to remove admin role in myopenhab.org (or at least less rights)

Hi all,

I would want to give less rights to the ‘myopenhab’ admin user to ensure a higher level of security may ‘myopenhab.org’ ever be hacked / the security breached.

I noticed that, when you login to myopenhab, it is possible to alter the openhab setup. This sounds as a good idea: you can change your setup everywhere you are. However, since this also can mean my setup can be completely ruined (or even worse things could happen like turning on the heating unlimited, roller shutters moving up and down until broken, etc.).

My question: is there a way to prevent someone to mess up my configuration (messing up settings is still possible since one could set heating levels, roller shutter, etc.) but at least I could block any access?

I am running openhab 4.1.1 in docker (NAS).

I very rarely use myopenhab, but during vacations it is nice to see what is going on.

Any ideas?

I think, you are mixing things up here.
myopenHAB ist just a special kind of proxy, and gives only access to openHAB’s REST endpoints.
Therefore, there is no way to limit access rights in myopenHAB.
openHAB itself does not have a real RBAC (role based access control) but you can limit what a not logged in user can see/do by creating MainUI pages for those.

Hi Hans-Jörg,

Thx for your fast reaction. It is a ‘special kind of proxy’ as I understood (not that I have that much in-depth knowledge). But I thought that it is working through the cloud connector and therefor one could limit (in someway) the access to openhab (via a setting in the cloud connector that I did not find / knew).

Just for me to understand:

  • myopenhab.org has the possibility for users to login (obviously :slight_smile: )
  • These users are linked to my dashboard
  • To gain admin access I then have to login as my local admin (what I configured in openhab not in myopenhab)

I can not prevent that someone is logging in as admin, right?
Alternative (if understood correctly by me) would be another page (subset of my actual as another sitemap / openhab instance / mainUI) which doesn’t offer to much functionality and if compromised, that would all that has been lost? Since openhab doesn’t offer that much functionality, one would not be able to sniff what could be changed or added as things or items.

Can’t the usage of the REST not be limited in some ‘sneaky’ way?

Best regards

Yes, it is working through the cloud connector. But the main thing the cloud connector does is opening a secured path to our myopenHAB service. Therefore, no ports have to be opened which can be accessed from outside.

Some of our REST endpoints need user role „admin“, that’s why you don’t see all the config stuff in MainUI without logging in as admin.
So make all your „critical“ pages visible to admin only and don’t configure your openHAB mobile app to use admin login.

Thanks for clarifying.

What I don’t understand: the username / password I login to the website isn’t the username / password of my admin on my local installation. However I can login via the website (myopenhab) as admin via an additional login (unlock mainUI). This can not be prevented, or can it? I understand not using admin in the mobile app, but via the webpage I can login as admin. Or did I configure something completely wrong?

I want to elaborate a bit on @hmerk’s answer which is spot on but for future readers aI want to provide some detail.

First some facts:

  1. openHAB implements authentication and authorization independently from myopenhab.org.
  2. openHAB supports two roles: admin and user.
    a. admin users have access to the full openHAB REST API
    b. users only have access to those openHAB REST API endpoints required to render and use the UIs (i.e. items, sitemaps, etc.)
  3. by default, openHAB enables a setting called “Implicit User Role” which allows non-authenticated and authorized users from accessing all of 2.b. If you disable this setting all users must log in before they can access anything in openHAB.
  4. authentication to myopenhab.org is separate and independent from the authentication described in 2. So a user could log into myopenhab.org but still not be able to access anything in openHAB without further logging in.

So it is possible to set it up such that

  • myopenhab.org has the possibility for user to login
  • these users must then log in a second time to access the dashboard
  • to gain admin access a user must login using an account with the admin role.

That’s why there’s a password. The password prevents someone from logging in as admin. Assuming no other unknown vulnerabilities, the amount of time required to brute force your password is as follows:

Choose a 12 letter password using uppercase, lowercase, numbers and special characters and your admin account should be protected for a little over two centuries.

But lets assume that there are vulnerabilities. In order for someone to get through to your system they would have to first crack into the openHAB Cloud Service and then they would need to find and exploit a second wholly different vulnerability to break into your openHAB instance. Definitely not impossible but most likely something a casual hacker isn’t going to bother with.

No, this cannot be prevented. If it were prevented, it would be prevented everywhere, even on your local network. You’d be locked out of admin on the openHAB server everywhere.

2 Likes

Hello Rich and Hans-Jörg,

Both thanks for your answers and clarifications. For now, good to know what has been put in place to prevent any unauthorized access. I will think of putting up a second instance which connects to myopenhab with very limited possibilities regarding settings.

Again: thanks a lot. As usual. :slight_smile:

If you don’t trust openHAB’s password based auth and auth implementation and you don’t trust myopenhab.org, you will be better off:

  1. ensuring that openHAB is not accessible from the internet in any way, even through myopenhab.org
  2. using a VPN to connect remote devices to your local network and only allow remote access through the VPN

Deploying a second instance of OH to connect to myopenhab.org greatly increases your complexity and mitigates any security risk by very little if at all.

1 Like

As @rlkoshak already said, this will ad more complexity and is not really needed.
Create pages in mainUI with only basic functions that cannot harm. The rest, limit to user admin.

Just to be clear: it is my password that I don’t thrust. As far as I have seen upto now, your implementation is state of the art.

I have been thinking last night of creating another instance, that would indeed solve nothing. I think I will stick to the current implementation since adding vpn only makes my infrastructure more complex (two packages to maintain). I will dive however into Hans-Jorg’s remark about limiting user admin. Thx.

1 Like

Please feel free to ask if you need assistance.

Well, it seems like addressing that is going to be the best approach over all to improving your security. As should be evident from the chart above, it really doesn’t take that much to create a really secure password. Pl3aseD0n'tUseTh1sP@ssw0rd! would trillions of years to brute force crack without other information to narrow the search down (that’s why you shouldn’t use personal information in passwords).

It doesn’t take much to create a good and secure password, even one that you can remember. Standard advice for good passwords include:

  • at least 12 characters, more is better; pass phrases help with this
  • at least include numbers, upper and lower case letters
  • do not reuse passwords; a password manager (I like Bitwarden but there are others) can greatly help with this but if you don’t have one at least limit the reuse of passwords. Definitely use a unique password for each important account such as email, banks, PayPal, etc.

If you trust the implementation, then you have full control over how secure your account is based on the quality of the password you choose.

Thanks again both for your replies. Sorry this is a bit later than you may have expected.

What I have done:

  • new password (a bit overdone probably: 17 positions including all the advice @rlkoshak gave, so numbers, upper / lower case but also other ASCII characters). It was already good, but now must be unbeatable. :slight_smile:
  • checked my setup at openhab, but here are some questions (just to make sure I understand it correctly):
    → only mainUI supports functionality for different pages for admin and a not-logged-in user where the ‘sitemap’ offers everything to everyone, right? This is what @hmerk is pointing to? If so, check (done)
    → can I somewhere change the username ‘admin’ in the openhab settings? I did find some ways to change the password, but could not find a way to change the name. Is that even possible?

Sitemaps (BasicUI) do not give access to thing or item config. This is possible only in mainUI as admin user.

I am out of country, so cannot really check, but I think you cannot rename the admin account. You might need to delete and recreate it with a different name.
Just a guess…

Correct. In truth there really is no concept of users for sitemaps at all. Either you have the implicit user role turned on in which case all sitemaps can be accessed by anyone with the URL, or you have the implicit user role turned off in which case someone with the URL myst first log in to access a sitemap. But once logged in they can access any and all sitemaps.

As @hmerk indicates, the difference between a user role and admin role is that users can only access Items and a couple of other related REST API endpoints required to drive UIs like sitemaps, whereas admin users can access rules, Things, and everything else in addition to Items.

I doubt it. You’ll probably need to add a new user with the admin role and then delete the old one.