121–130 of 181 posts
Earlier quoted context omitted.
The stuff on the shelf, sure, but you can always go 'prosumer-grade' like Ubiquiti or Mikrotik for hardware that actually receives timely updates and has competently written firmware.
Ubiquiti is awful, it's a cloud-centric ecosystem. The best "prosumer-grade" stuff is probably OpenWrt. If you need more power, opnSense or a plain Linux distro on an x86 machine.
Does anyone have a good reference for which tapo cameras support rtsp? I have a c210 that works well (sort of, you can't use it with their cloud capture) and I have it working with frigate. But today I got a c402 (outdoor) thinking I could use it to capture my son's soccer practice. But that doesn't have the camera account option under advanced. I love the price point of these devices but the functionality is all ove…
You should still be able to use the tapo:// go2rtc stream source even if the camera does not support the rtsp:// via the camera account option. Have a look at my frigate configuration for reference - https://github.com/kennedn/frigate/blob/7c56604e819d2cb1da28...
Why do you use rtsp for some streams and then tapo protocol for others? Are these all tapo cameras?
IoT security is generally terrible, but the fact that consumer routers are essentially unaudited black boxes processing all your network traffic is genuinely concerning. Most people have no idea their router firmware hasn't been updated in years and is probably running known CVEs. The supply chain trust model for networking hardware is broken.
I think IoT demands a rethink of security.
Like sometimes I want IoT devices to just bloody connect, and if I have to use a published exploit that circumvents online only requirements I will do it.
But some people do genuinely have use cases for cloud speaking IoT stuff.
Really I think the device should ask at first run, and then burn in your response and act only in the selected mode. If you want it to require Cloud MFA, thats an option, if you want to piss python at your lightbulb to make it blink, then thats where it lives permanently.
IoT security is generally terrible, but the fact that consumer routers are essentially unaudited black boxes processing all your network traffic is genuinely concerning. Most people have no idea their router firmware hasn't been updated in years and is probably running known CVEs. The supply chain trust model for networking hardware is broken.
Most people are using routers given to them (and configured by) their ISP... so really they are blackboxes connected to an upstream blackbox for most people. I am always surprised by how many people give me their ISP chosen router name and ISP chosen password when I connect to their WiFi. I don't want to give my ISP that much control.
Coz I would absolutely 100% not be surprised for your average consumer.
For your average HN reader I would hope they treat whatever their ISP gave them as just some dumb "switch" type device that sits outside their trusted network and handles nothing but encrypted traffic. Like my ISPs device definitely does have a WiFi and such, which I disabled. I treat it as a bridge / modem and it's definitely not part of my "inner circle". Hasn't been in 25 years.
IoT security is generally terrible, but the fact that consumer routers are essentially unaudited black boxes processing all your network traffic is genuinely concerning. Most people have no idea their router firmware hasn't been updated in years and is probably running known CVEs. The supply chain trust model for networking hardware is broken.
There are countless routers in between you and your destination which you can't audit anyway. End devices long since consider the routers to be compromised and have everything verified and encrypted in transit. So unless your router is participating in a DDoS or mining bitcoins it doesn't really matter how secure it is.
Comparing a residential router to a network operator’s router is spurious: those routers don’t perform any sort of filtering for the public internet traffic flowing through them.
IoT security is generally terrible, but the fact that consumer routers are essentially unaudited black boxes processing all your network traffic is genuinely concerning. Most people have no idea their router firmware hasn't been updated in years and is probably running known CVEs. The supply chain trust model for networking hardware is broken.
IoT security is generally terrible, but the fact that consumer routers are essentially unaudited black boxes processing all your network traffic is genuinely concerning. Most people have no idea their router firmware hasn't been updated in years and is probably running known CVEs. The supply chain trust model for networking hardware is broken.
IoT security is generally terrible, but the fact that consumer routers are essentially unaudited black boxes processing all your network traffic is genuinely concerning. Most people have no idea their router firmware hasn't been updated in years and is probably running known CVEs. The supply chain trust model for networking hardware is broken.
Your point of course stands, the situation is terrible.
Earlier quoted context omitted.
It's a hardcoded default password, not a permanent backdoor. If I'm understanding the post correctly, the user changes it as part of the onboarding flow. This is the way most apps work if they have a default password the user is supposed to change.
The device should ideally have some kind of secret material derived per device, like a passphrase generated from an MCU serial number or provisioned into EEPROM and printed on a label on the device. Some form of "enter the code on the device" or "scan the QR code on the device" could then mutually authenticate the app using proof-of-presence rather than hardcoded passwords. This can still be done completely offline w…
Thats the wrong way to do it, just require the user create a secret on first boot, and have factory reset functionality for when you forget it.