No, it is a good idea. If someone is operating or changing settings on your baby monitor, doorbell camera, garage door opener, smart switch, light bulb, etc -- the developer should check to make sure that the actor doing so is authorized to do it.
Why in the world would anyone want unauthenticated access to these devices?
All of those things might have a authentication-free use-case for e.g. a babysitter (maybe not to change settings, but to use). For personal networks, being on your local LAN is in practice a decent form of authentication given the tradeoffs of otherwise having to manage credentials.
That seems a bit contrived. I would expect my babysitter to be observing a child in-person, not remotely.
Regardless, the commonly expected use case for IoT devices is for people to be able to access them from their mobile device, on the internet (thus the 'I' in IoT). IoT devices, as their name implies, are on the internet, and need authentication because of this.
The problem is that this use case is real, and people are buying these devices, and so, how do we make them better? "Just don't do that" doesn't address the problem, it's a dismissal of it.
We use a camera in our daughter's nursery to see whether she's going to fall asleep (if protesting a nap/bed time after laying her down) or whether she's standing in her crib/too wound up. We also use it to keep track of whether she's woken up if we're out in the yard. I do actually have the ability to access it over the Internet through wireguard, but that's something I never need. LAN access suffices.
IoT is a marketing term. Networked devices don't necessarily need to use the Internet, and indeed most of the time there isn't even a use-case. You're going to open your garage while you're at the store?
Honestly I don't see the use-case for almost any IoT thing though. It mostly seems like gimmicks (color changing/dimming lights) or adding unnecessary complications that make it less secure and more failure prone so that someone can sell you a service (a cloud app for your garage instead of a remote/keypad, an app for your door instead of a key).
Glad it works for you with your use case. But you have to recognize that you are much more knowledgable than most in this realm. The majority of people expect these smart devices to be accessible from the internet, and do not have the ability or knowledge to configure remote access VPNs.
> You're going to open your garage while you're at the store?
One would mostly likely want to close it then :)
But really, I have an IoT garage door opener so that I can check to make sure it is closed if I forget. This is a common use case. Also, opening it for others when you are away.
> Honestly I don't see the use-case for almost any IoT thing though.
Okay, here's a few: Cameras are useful to see when people are at your house, when packages arrive, etc. Security sensors (or the aforementioned cameras) are also useful to check on the security of your home while you are away and respond if something unordinary happens. People like automatic pet feeders and automatic vacuums to perform tasks while they are away. People like thermostats that can be changed to more economical settings while away, and returned to comfortable settings when (or shortly before) they arrive. AirBnB hosts like being able to change the door code on their properties between visitors, and to monitor and secure their property while not physically there.
If you want some more, just read the reviews of these devices on a site like Amazon, and you'll see what people use them for.
People buy them because they find them useful. That doesn't mean you have to like them or want them. But an initiative to encourage manufacturers to implement basic best-practices is a good idea for other people regardless of whether you personally want them or not.
Don't automatic pet feeders run on timers? And vacuums run on a timer + sensors? And thermostats run on a timer + sensors? I'm not seeing why any of those would be on a network, much less the Internet. In order to put them on a network in the first place, you'd need to have a way to configure it locally (e.g. bluetooth), so why wouldn't you just set schedules there? The whole point of automation is that you set it up once (like when you open it) and then never touch it again. Again, best practice would be to never connect it to a network at all.
The AirBnB use-case seems fair enough. I'll still maintain that having devices connect to hostile C&C servers (which is the current status quo) is not a basic best-practice or an incremental improvement. The recent story about inverters being bricked by a distributor demonstrates why. Literally damaging electrical infrastructure (which is what happened) is one of the the boogeymen used to push for better security, and can put people's lives at risk. That attack should have never been possible.
> Don't automatic pet feeders run on timers? And vacuums run on a timer + sensors? And thermostats run on a timer + sensors? I'm not seeing why any of those would be on a network, much less the Internet.
The ones that are on the internet also allow you to trigger them remotely, monitor status, trigger automatically based on geo-location, etc.
Are you trying to say that people could do things another way? Of course they could. But they aren't. They are buying IoT devices, because they like the features.
Personally, I like to set my turn my thermostat off of the eco temperatures before I go home, which is not at the same time every day. I don't think this is a strange use case.
Also, I like to trigger my vacuum remotely when I'm already out of the house. I don't leave the house at the same time every day, so I don't have it set on a timer. I could turn it on before I leave, but I don't really want it trying to roll out the door or bump into me while I'm putting my coat and shoes on.
Again, your critique here seems to be your own person dismissal of these features, which really isn't relevant. Other people buy and use them.
It's more that if you are at all concerned about security, then by far your biggest threat to worry about is the provider of cloud services, so that needs to be your starting point. In practice, any home network in the last 20 years is behind a firewall that blocks incoming connections unless you go out of your way to open the firewall/forward ports, and will be secure from other attackers by default. There's no point in discussing security if your threat model is completely wrong.
It's not random hackers in Russia that rendered people's solar setups inoperable. It's the inverter company using their backdoor. Ubiquitous backdoors and pre-bundled malware are the top security problems in the industry.
> It's more that if you are at all concerned about security, then by far your biggest threat to worry about is the provider of cloud services, so that needs to be your starting point.
I don't necessarily agree with that. The most widespread and issues to hit people in the US in recent years are not malicious cloud providers, but credential stuffing attacks against otherwise legitimate and reputable services.
> In practice, any home network in the last 20 years is behind a firewall that blocks incoming connections unless you go out of your way to open the firewall/forward ports, and will be secure from other attackers by default.
Right, the instructions with those legacy IP cameras instructed users to open ports to access them remotely.
> It's not random hackers in Russia that rendered people's solar setups inoperable. It's the inverter company using their backdoor.
Yeah, that's a problem. But probably not addressable through this program. There's nothing a voluntarily labelling program can do to protect you from a vendor that wants to fuck you over. One would presume a bad actor would simply: not volunteer to give up their ability to be bad.
Protecting customers from vendor abuses is not just a cybersecurity problem, it's a warranty and contract problem (or criminal fraud problem), and is probably better handled that way.
> If someone is operating or changing settings on your baby monitor, doorbell camera, garage door opener, smart switch, light bulb, etc -- the developer should check to make sure that the actor doing so is authorized to do it.
There is a well-established pattern for this that's as old as humanity itself: if you can physically reach the device, you can operate the device. Security is established by the fact that you have to be authenticated and authorized to be in the same room as the device, and if extra security is needed, then various social, physical and digital forms of keys and interlocks exist.
This naturally extends itself to operating networked[0] devices too - if you can get on LAN, you can access them. Yes, I know this doesn't exactly fly in an office, but see the keys&interlocks stuff above. And despite what security people would say, you don't need anything more than that for home (or even SMB) use. Your IoT lightbulb does not need bank-level[1] security[2].
Nor does your non-Internet connected lightbulb or fridge. Which is kind of the other point I wanted to make: non-networked devices neither need nor should go beyond the centuries-old "can reach it = can use it, +/- social norms" pattern; this means we also need to actively discourage the problem-pattern that's common today, and goes like this:
1) Connecting a device to Internet for dubious, often user-hostile reasons, then
2) Bringing up NIST security requirements and implementing them, then
3) Turning around and using all that security work to justify the Internet connection.
No, your device does not need automatic OTA updates. That's just sleight of hand - what it actually needs is to not be connected to your servers in the first place - then all the security requirements are no longer requirements.
--
[0] - Not Internet. I in IoT is bullshit 99% of the time, remaining 1% of the time it should be handled by a VPN - or even a Home Assistant instance, since 100% of IoT apps are bullshit and are better replaced with Home Assistant app + whatever vendor integration for HA the community hacked up in their free time.
[1] - Ironically, banks actually suck at this, but the analogy makes sense in theory.
[2] - Almost nothing does; we're currently dealing with runaway over-securing of everything digital, because everyone and their dog thinks their app is Special and their service is Important. News flash: it isn't. All this is doing is making software and hardware more annoying to use and footgun-rich - and of course entrenching the adtech surveillance business model.
> the device requires users to authenticate