Thats not it. If your hub is registered with the cloud and you login to your account on the hubitat app on your phone, regardless if you are on your LAN or not, you have will have access and control over every device in your home.
In other words, every device in your house is only secured by your hubitat username and password.
Edit: Even removing the hub from my list of registered hubs on my.hubitat.com doesn't remove this issue. I can still control all of my devices within the hubitat app even if I'm off of my LAN
Yes. I now just reset my password on my.hubitat.com and opened the hubitat app again. I was STILL able to control my devices. I was however on wifi but still....There should be some sort of reset for logged in users when a password is reset.
You can now see where this scenario goes...If someone logs into my account and has control over my devices, a password reset won't even force them off.
This is done via Oauth, not your username/password after the fact. To reset the authentication token, I suspect that removing the Mobile App Device from your hub -- the one that corresponds to this particular mobile app as you chose upon setup (generally the name of your phone, tablet, etc., though you can choose that), should you have more than one -- would do it.
If it addresses the concern, I'm not sure why it isn't a "real" solution. Regardless, I don't really see any other way it could work given that it's authenticated entirely via this access token (and sort of your hub UID, which you can't change). This token is stored on your hub -- your My Hubitat/cloud credentials aren't involved at this point, and Hubitat's cloud servers don't do much except act as a relay into your hub to facilitate this communication.
Ah I think I understand. And after doing a little test, You do not have access to all of the devices in the "lights/switches" section until you connect to the lan which hosts the hubitat hub.
I uninstalled the app on my phone and disconnected from wifi. Reinstalled the app on cell service and logged into my account. I then created a new device which worked fine however there was nothing under the "lights/switches" section. I then connected to wifi and everything was there.
So this is where the initial 0auth exchange is occurring and it must be using the local IP of the phone to validate its acceptable to add the phone.
@bobbyD All the other issues aside, it would be a good "best practice" to allow optional 2FA for signing into the Hubitat cloud services. Text message 2FA is better than nothing but also one of the Auth Apps (Google Authenticator, Microsoft's version, etc.) would be good.
2FA across the board on the cloud connection would break SO MANY things in terms of 3rd party connections (and remote maker api usage, so not just 3rd party).
The devs will have to think of a different solution, if/when it becomes a priority to implement something new in this area. 2FA for the app, and different auth method(s) for apps/integrations (unique long term use keys that can be revoked, or other) seems more likely.
I haven't heard of any activity/work in this space, so I wouldn't expect something "soon", but people should definitely keep submitting their feature request on this for consideration. While they don't base their development list solely on feature requests, they do listen.
I'm not sure I understand what 2FA on login would or could break (admittedly have not looked deeply into it).
You can generate an auth token with credentials (should require 2FA IMO, given the level of access given to resources)
You can generate auth tokens from the admin interface (e.g. MakerAPI, RM, etc), those don't require 2FA and won't be broken by applying 2FA to the login flow. You control the scope of resources they give access to and you can revoke them.
Maybe you are right, I haven't thought all the way through it either I guess.
That said, the oauth token at the app level is after the cloud connection already hits your hub (aka it passed all the way through the cloud and hit your end device already). I would think most would prefer to stop the connection before it even makes it all the way to your hub - at the cloud connection attempt itself.
But again, I haven't put much thought into this, and don't really care about it that much either, so probably won't.
The current method they are using, while not 2FA, is still somewhat safe IMO. If someone logs into your account on their phone app and adds their own phone, they cannot control anything until that phone itself makes connection to the same lan the hubitat is on. Once that's done however, control of every device is possible whether or not your phone is on your LAN or not, but it's that initial connection which authorizes it.
I tested this on my end. So while it doesn't solve my initial issue of preventing all devices from being exposed on the app level, it does ease my security concerns.
Yeah would be great if there was some form of user-configurable API management on HE's cloud platform. It's a free service however and unless they want to make it a business I wouldn't hold my breath.
Anyway the oAuth token being essentially generated from credentials, 2FA flow would apply if available. Iām thinking about linking of services like Alexa, IFTTT, etc. In the current situation, as long as one can restrict what hub resources are made available to these integrations via that token, it's manageable.
That said in 2024 I don't think it's unreasonable to expect a service not to convert passwords directly into auth tokens.
p.s. a simple audit trail (e.g. last 20 logins with IP) would be nice
I wasn't thinking of requiring 2FA for all interactions--only initial logins that allow access to the account. That should prevent people from accessing the account and associated hubs with only an ID and password.
Of course, it wouldn't do much for anyone who had one of the GUID based links that the dashboards use.
If they wanted to go deeper into 2FA and require some form of 2FA for the other accesses (that likely/should be using the GUID-type URLs), it would probably best be done as an optional setting using a newly defined method so people could choose whether or not it was worth it (and so the developers could adapt to the new method without breaking current apps).
