121–130 of 245 posts
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"?
TLS + Client Certs + EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
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…
Would you feel comfortable with end-to-end encryption via an open, documented, free protocol? This is literally my raison d'être as a company, so I'd be interested to hear your comfort level. 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…
Earlier quoted context omitted.
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.
If you're using a custom client-side app to access the device, which many of these things seem to do, you can create a CA for the devices, put the public cert for the CA into the app, and issue each device an individual cert at the factory signed by that CA. Then the app can be reasonably secure and assured. I say only "reasonably" because defending against the "I cracked into the device and stole its cert" is pretty…
If the user really cares about security enough, they can buy their own real TLS cert and install the cert on the brick.
> Eventually I plugged my phone into my laptop and ran adb logcat, and the Android debug logs told me that the app was trying to modify a network that it hadn't created. Apparently this isn't permitted as of Android 6, but the app was handling this denial by just trying again. I deleted the network from the system settings, restarted the app, and this time the app created the network record and could modify it. It st…
As a counter example, my brother who never uses a computer setup his chromecast in 5 minutes with zero help from me. I know b/c he called me and asked for help. I told him he wouldn't need it, but he didn't believe me. Things are getting better. There will always be more crap out there than good stuff. That's why walmart is so popular, but things will generally improve.
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…
I want a simple device like this: 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, a…
Sounds like there is a strong need for a standard OS build for IoT devices. I'm not expert in the area, but I would imagine a standard API could be implemented to handle the vast majority of use cases. Connecting to an app securely, turning things on and off, basic scheduling.
Earlier quoted context omitted.
If you're using a custom client-side app to access the device, which many of these things seem to do, you can create a CA for the devices, put the public cert for the CA into the app, and issue each device an individual cert at the factory signed by that CA. Then the app can be reasonably secure and assured. I say only "reasonably" because defending against the "I cracked into the device and stole its cert" is pretty…
Nobody's going to invest money into flashing each device with an individual cert just to protect against an attacker MITMing a home user's home wifi network to turn off a lamp. And you'd have to bundle your own whole TLS stack and browser with the app just to get the CA validated; that's a lot of extra software engineering. If the user really cares about security enough, they can buy their own real TLS cert and insta…
Of course, one person steals that cert and they've cracked the system wide open. But that's the default case for crap crypto anyhow, so what's the difference, except you spent about 10 minutes in the shell and passed some parameters to your library instead of spending.... well... anything more than 10 minutes futzing around with AES and RSA and so on?
Also, while I understand your use of "nobody" in the slangy English sense rather than the strict mathematical sense, I would point out that as these devices get more sophisticated, eventually they tend towards a manufacturing process that will do something to each one in the factory anyhow. For instance, if you're doing any sort of burn-in testing you've already done the vast bulk of the hard work it would take to also use that time to stick a cert on there. Yeah, your cheap knock-off Wifi light won't do that, but as the industry matures I think you'll see practices that would permit certs without much additional work.
Earlier quoted context omitted.
I want a simple device like this: 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, a…
Will there be soft start, and if so do you count that as another feature?
Has anyone ever bought a consumer network appliance that didn't have shitty security?
Has a security engineer ever reviewed anything that had good security?
So there is a great amount of lists, blogposts and information about awful/bad IoT things, but if someone like me want to have a list about IoT things that are actually secure and well-working, where would I find that?
I'd love a list like that as well, but sadly I don't think one exists and I don't think there's any money in doing it. Nobody wants to hear about good IoT devices, they want to make fun of bad ones and feel superior, that's what sells clicks. Maybe i'm just being cynical...
Perhaps an open-source effort to document & track what work has been done, even if it's just pulling firmware images and taking a look around. Maybe some kind of gamification to motivate researchers to pull things apart and report what they see.