111–120 of 245 posts
Earlier quoted context omitted.
It's not that easy. I stick with brands/products that are reviewed by people I trust or have seemed to pick up some momentum. My general rule of thumb is I NEVER buy anything IoT that is WiFi based. Zigbee or Z-Wave based devices will save you a lot of security nightmares (though definitely not all).
Why is Z* preferable to Wifi-based?
Earlier quoted context omitted.
As usual, "it depends". If this thing is capable of running OpenWRT, it can run some sort of SSL for what it needs. Might be tight and might have to not be OpenSSL, but it can be done. Lesser-capable devices may have issues. But note that one way or another, the devices must speak some decent encryption to get on to WPA2 networks. Of course that's probably done in the Wifi hardware, but it still shows that it's not l…
But more to the point: there is no purpose to SSL/TLS on an appliance because it will not have a valid certificate, hence it won't protect anything. You might as well just use WPA2-PSK.
I say only "reasonably" because defending against the "I cracked into the device and stole its cert" is pretty hard, but I'd submit, also not all that realistic a threat in this case. I'm really looking to defend more against "I bashed together some encryption so crappy I can hack this by making you visit a hostile web page" than "I want to use this lightbulb without the NSA knowing". (On that note, an SSL cert only valid to a custom app that your browser won't accept isn't all bad, it prevents that sort of thing.)
I mean, this it total pie-in-the-sky in terms of the ask I'm making here for security knowledge and willingness to do something correctly instead of bashing out some terrible, incorrect crypto with direct and incorrect use of the primitives. But it's possible.
Actually... I won't call myself an SSL expert per se, but one of the things that I find personally frustrating in dealing with some people is that once you do know what's going on, using SSL is often much much simpler than bashing together your own crap crypto. Any sensible SSL library has places to stick the CA certs. Generating them isn't that hard, more just tedious. Generating a big pile of certs at the factory and siging them isn't that hard. Even if you're very sloppy with your SSL usage, where you don't do a great job of protecting your core cert, where you use the root of the CA instead of an intermediate so the private key of the root is "live" in the factory, you don't set up a good revocation solution and you just set the expiration as far into the future as you can, because you probably haven't got a mechanism for updating them... even if you make all those errors, it's still better than just bashing crap crypto together, because it'll still resist more attacks than your crap crypto and it's not really all that hard.
But I have abundant experience that shows people would way rather futz around directly with RSA keys and HMAC and spend days and weeks scraping something together rather than even entertain the suggestion of doing it even half correctly. I don't fully understand it. Do other people find futzing with crypto that fun? I play defense a lot in security, but I honestly find correct crypto a royal pain in the ass and do everything I can to outsource it via SSL (which may not be perfect but isn't necessarily bad and has the advantage of being very defensible when people ask "what do you do to secure things") or NaCL or something. Is it just the psychological difficulty of admitting that you don't really know what you're doing with this crypto stuff? I dunno.
Has anyone ever bought a consumer network appliance that didn't have shitty security?
I just blogged about this yesterday. In short: > The line in the sand for me is: network vs cloud-based systems. I want things to be network connected, but I want it for my own network only. I want to be able to control my coffee pot, but only from home. If I choose to expose this over the internet, great! It's up to me to make sure it's secure. I don't want anyone making that decision for me. I also want it to be up…
What I've got is a platform that 1.) makes it substantially easier for IoT developers to get their devices to market and 2.} enforces end-to-end encryption and affirmative consensual sharing. It works by running as a background service on both the IoT device and on any connecting computers. In a similar vein to IPFS, the service magically switches between local and nonlocal networks dynamically, so it doesn't matter if your interent connection goes out; as long as you have power (and a local server set up, but I'd like to add P2P capability over LAN in the near future) you're good to go.
I realize this isn't the whole device you want, but is that a starting point you'd be interested in?
I enjoy reading this kind of article about lousy security, because I say to myself "Wow, that was lousy!" and laugh. BUT I still don't know how I could avoid this. I genuinely ask: could anyone share with me the "2016 Guide of the best pratices for securing an API/ a web app"?
>It's running Linux and includes Busybox and dnsmasq, so plenty of GPLed code. I emailed the manufacturer asking for a copy and got told that they wouldn't give it to me, which is unsurprising but still disappointing. Has the GPL really lost it's power that much? I mean not responding to inquiries is one thing, but outright saying no?
> Has the GPL really lost it's power that much? It's up to the copyright holder to enforce it.
I just blogged about this yesterday. In short: > The line in the sand for me is: network vs cloud-based systems. I want things to be network connected, but I want it for my own network only. I want to be able to control my coffee pot, but only from home. If I choose to expose this over the internet, great! It's up to me to make sure it's secure. I don't want anyone making that decision for me. I also want it to be up…
1. It plugs into the wall
2. You can plug an appliance of some sort into it
3. The device has a USB interface
4. The device has a WiFi interface
5. When I plug in the device with the USB interface, it looks like a serial device
6. The device has a very simple protocol that you can use to set it up, over the serial interface
7. You can optionally have the device join a WiFi network, and you can choose to enable a simple REST web service
8. Whether you choose USB or Wifi, the device only does 3 things:
a. Tell you whether it is supplying power to the appliance
b. Supply power to the appliance, if not already doing so
c. Stop supplying power to the appliance, if not already doing so
edit:formatting
Earlier quoted context omitted.
Which problems do you want to solve with these IoT devices? What should they do? In my opinion existing IoT devices generally replace simple, proven systems with complex and abstruse ones.
A good example would be the smart outlet ones, so I could for example setup one to automatically power cycle my cable modem and router, or even one that could handle the load of a space heater I keep in my office during the winter months and switch it on 15 minutes before I get home. I don't even need the ability to manage it over the WAN, I'd be fine with just something my linux boxes at home could handle with cron…
Earlier quoted context omitted.
Why is Z* preferable to Wifi-based?
One of the reasons would be that it isn't used that often and won't allow access to your network with commodity hardware.