Great points! I agree with the concerns, and I don't leave the microwave turned on at the moment.
I agree that the microwave webpage should be password-protected or disabled, because really, it's not the most important feature. If I was living in an apartment with a shared network, everything would be running behind a firewall.
The cooking database website is the only part accessible from the internet, and is running on a separate server. I've added a temporary lock for my products, so no-one can edit or delete them at the moment. In the future I might implement some better ways to prevent abuse. I haven't set up SSL yet, but will do it if the site starts getting some use. I've added the following notice for now:
> This website is not currently secure. If you submit your password on this form, a hacker will be able to read it, especially if you are using an unsecured wifi connection. However, it is safe to sign in with Facebook, Google, or GitHub.
Linux (Raspbian) is in charge of setting the time via NTP, so any vulnerability is not specific to my project. The tweeting is dumb, but just a fun thing to put in a blog post. And voice commands must be prefixed with the 'microwave' keyword, unless the microwave door has been closed less than 10 seconds ago.
Totally cool. I understand that it's a custom prototype/ proof-of-concept project. Network topology is definitely the major factor determining any real security exposure of the appliance on a given network, but it seemed like an undocumented variable that exists outside the scope of this particular project, so I figured it's worth pointing out.
As zanny pointed out (https://news.ycombinator.com/item?id=6030206), since we know the chipset, and can anticipate available features, given that we know the networked device is a Raspberry Pi, and that we have the source code of the project, this provides us with enough information to craft possible payloads to drop onto the system. It's certainly not a huge attack surface, but there might be _just_ enough wiggle room to bust in.
As for the QR Code concept, any chance of some plans for adding a small low-end camera?
Even if the camera is not very good (maybe a $20 USB webcam), and the picture is poor quality (perhaps a ~0.3 megapixel image), as long as the image of the QR Code can be captured, the software that attempts to discover the QR Code and pull the information out of the low-quality image will do the rest. Then, it's just up to the user to print out some QR code stickers. Actually, come to think of it, I bet there are probably some burritos out there with QR codes on the wrappers, pointing to some burrito website, that could be re-purposed to trigger the microwave.
I agree that the microwave webpage should be password-protected or disabled, because really, it's not the most important feature. If I was living in an apartment with a shared network, everything would be running behind a firewall.
The cooking database website is the only part accessible from the internet, and is running on a separate server. I've added a temporary lock for my products, so no-one can edit or delete them at the moment. In the future I might implement some better ways to prevent abuse. I haven't set up SSL yet, but will do it if the site starts getting some use. I've added the following notice for now:
> This website is not currently secure. If you submit your password on this form, a hacker will be able to read it, especially if you are using an unsecured wifi connection. However, it is safe to sign in with Facebook, Google, or GitHub.
Linux (Raspbian) is in charge of setting the time via NTP, so any vulnerability is not specific to my project. The tweeting is dumb, but just a fun thing to put in a blog post. And voice commands must be prefixed with the 'microwave' keyword, unless the microwave door has been closed less than 10 seconds ago.