Manage storage of user credentials

Hi everyone,

I work actually in the improvement of the role-based access control of openhab. I have install openhabian. In the users.json file are stored information such as users’ roles and their encrypted passwords. This file is located for my case in /var/lib/openhab/jsondb/users.json as
explain here in the documentation of openhab:

This file is create during the execution of openhab (because it is store in the var directory).

Someone know which file generate the file users.json? And which file check the credential of the users of openhab? I want to check if the file containing the users credentials are well managed. I want to investigate if the integrity of the file is well verified for each user connection for example. I would like to control that a user with super user rights and access to the openhabian file system cannot modify the file (database) containing user credentials to avoid corruption of openhab users.

Chances are it’s already well managed, but I wanted to check. Someone know where the users credentials are verified and manipulated in the file system of openhabian ?

Thank you for your help,

Nicolas Gennart.

Don’t mix and confuse openHAB with openHABian.
The openHAB user credentials (which then ultimately get stored in that json file) are managed through Karaf console commands (openhab:users I think), read the openhab docs (on console probably).
So you also should neither access nor change this through the file system.

Also change the thread title please. “User credentials” in openHABian are Linux users and totally unrelated.

Yes, I know how users are managed, I am currently doing the command to list, add and remove a user’s role as requested in this issue :

But my question is how the file that store the user credentials are manage ? Is it stored in the same way as the users in Linux? Because in the /etc/shadow file, there is none of the users I created. Which file generates the file users.json ? I try to understand exactly how the users credentials are store and manage in openhab to improve the security.

I want to verify the integrity of the file that stores user credentials each time a user logs in. To prevent an attacker with superuser rights from completely tampering with the file that stores user credentials, gain full access to the openhab and block access from other users.

Thank you,

Nicolas Gennart.

Hmm, why do you think that’s necessary ?
To have such access possibilities, an attacker needs to get to your console, so needs to be in your local LAN… If you did not expose your openHAB instance to the internet, which is a very bad idea, this is a very unlikely szenario, IMHO…

None. Karaf does. As I already said Linux users are totally unrelated.

This is another XY problem.
I agree with Hans-Jörg that it is a very unlikely scenario so not worth putting efforts into
(and if you still want to do that there’s simpler and more effective means such as to restrict access to console to known source IPs).

1 Like

Ok thanks,

This scenario can be a problem because for example in my case I connect to openhabian with a rasberry and with a VPN. Let’s say I have a vacation home and I want to manage it remotely. If an attacker manages to get hold of the file that stores the user credentials, the attacker can control everything that is connected to openhab and since it is too far away I can’t go there to for example disconnect the devices.

I will check how karaf handles this (Maybe I won’t be able to make any changes but I just want to check) and implement a better control for command execution in the karaf console as you said.

Thank you,

Nicolas Gennart.

… then he’s already on your box and can already do anything so your reasoning is broken.

You can tighten access to the console by editing

But there’s no such attackers that are interested in controlling your home.
Even in pandemic times the bad guys have many easier and more interesting targets at hand.
As I already said it’s not worth the effort. Just drop that idea and move on.

1 Like

I agree with Markus and Hans-Jörg that you are probably going about this from the wrong angle. But I’d like to explain a little bit more about why and how to circle around so you can find the right angle.

Consider the following formulas:

Risk = Likelihood * Impact
Likelihood = Chance vulnerability exists * Chance that a threat will exploit it

Impact is a number, often in terms of money, that represents how much it will cost you if the you are successfully attacked.

Obviously these formulas are not strictly quantitative but they help one think about the problem.

OK, so we have your root concern: an attacker blocks access to OH for other openHAB users.

How can the attacker do this? Here is where you need to brain storm and come up with all the ways that an attacker might do this. These are called the vulnerabilities. They might cut the power, jam the wifi, and so on.

Now here is where you’ve turned wrong.

  • Any way that an attacker could do this that requires physical access to the machine running OH means you’ve already lost (they can just unplug and smash the machine).

  • Any way that attacker can do this that requires root access to the machine itself means you’ve already lost (they can just systemctl stop openhab).

  • Any way that requires the attacker to have access to your LAN means you’ve probably got bigger problems than whether they deny your openHAB users access to openHAB which you should focus on mitigating instead.

NOTE: An attacker need not be human, which is why it’s often called a threat. Threats can include weather, fire, ants, etc.

Now you’ve iterated over the reasonable vulnerabilities pair those vulnerabilities with threats. In this case you are concerned about some nameless attacker exploiting a vulnerability to deny access to your openHAB users. How likely is that to occur? If you are someone who is of interest to a state actor it might actually be quite high. For most people, it will be quite low.

Now back to the risk calculation.

Come up with some number to represent the impact should your users lose access to OH. Now multiply it by the likelihood that an attacker will actually do that. Anything that you do to mitigate this risk should cost less than the risk.

So if the impact is $1000 and the likelihood is 5%, anything I do to mitigate that risk must cost less than $50. So remember that your time has value and anything that you do to mitigate the risk can impose opportunity costs as well.

Use these sorts of exercises to help you identify the big risks and focus your efforts on those. If you are running an OH system on a LAN that is not directly exposed to the internet, your time and effort is much better spent making sure your LAN is secure and your machine has backup power and stuff like that. Maybe spend a little bit of effort on locking down the network on your OH machine so only certain IPs even on the LAN can communicate with it. Lock down SSH so it requires a cert or both a cert and password to log in. That is the sort of thing that is worth doing. Doing integrity checks on the OH users file doesn’t actually mitigate anything. By the time the attacker can get to that file, they can achieve their goals in so many more effective and destructive ways.

In short, the mitigation costs way more than the risk.


ok thank you very much for your explanation.

Look for ManagedUserProvider, then UserRegistry and its implementation:


These files are responsible for managing user entries and, indirectly, their permissions through role list. The ManagedUserProvider is quite small as most of its work is delegated to StorageService which handles JSON form of data.

Hope that these help. Its possible to extend storage format, however in order to make use of additional input available there you need to push it over all above layers. Additionally you need then to find a way to make actual use of extra things you brought from storage layer.


1 Like

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.